Selvom du kun løst har fulgt begivenhederneaf hackergrupperne Anonym og LulzSec har du sandsynligvis hørt om websteder og tjenester, der er hacket, ligesom de berygtede Sony hacks. Har du nogensinde spekuleret på, hvordan de gør det?
Der er en række værktøjer og teknikker, derdisse grupper bruger, og selvom vi ikke prøver at give dig en manual til at gøre dette selv, er det nyttigt at forstå, hvad der foregår. To af angrebene, som du konsekvent hører om dem ved hjælp af, er “(Distribueret) Denial of Service” (DDoS) og “SQL Injections” (SQLI). Sådan fungerer de.
Billede af xKCD
Angreb på nægtelse af service
Hvad er det?
En "benægtelse af service" (undertiden kaldet a”Distribueret benægtelse af service” eller DDoS) angreb opstår, når et system, i dette tilfælde en webserver, modtager så mange anmodninger på én gang, at serverressourcerne er overbelastede, systemet simpelthen låser og lukker ned. Målet og resultatet af et vellykket DDoS-angreb er webstederne på målserveren ikke tilgængelige for legitime trafikanmodninger.
Hvordan virker det?
Logistikken for et DDoS-angreb forklares muligvis bedst med et eksempel.
Forestil dig, at en million mennesker (angriberen) fårsammen med målet om at hæmme Company X's forretning ved at nedkalde deres callcenter. Angriberen koordinerer, så de tirsdag kl. 9.00 ringer alle til firma Xs telefonnummer. Company Xs telefonsystem vil sandsynligvis ikke være i stand til at håndtere en million opkald på én gang, så alle de indkommende linjer bindes sammen af angriberen. Resultatet er, at legitime kundeopkald (dvs. dem, der ikke er angriberen), ikke slipper igennem, fordi telefonsystemet er bundet op til at håndtere opkaldene fra angriberen. Så i det væsentlige taber Company X potentielt forretninger på grund af, at de legitime anmodninger ikke er i stand til at komme igennem.
Et DDoS-angreb på en webserver fungerer nøjagtigtsamme måde. Fordi der næsten ikke er nogen måde at vide, hvad trafik hentes fra legitime anmodninger vs. angribere, indtil webserveren behandler anmodningen, er denne type angreb typisk meget effektiv.
Udførelse af angrebet
På grund af den "brute force" karakter af et DDoS-angreb,skal du have masser af computere alle koordineret for at angribe på samme tid. Når vi gennemgår vores callcenter-eksempel, ville dette kræve, at alle angribere både ved at ringe kl. 9 og faktisk ringe på det tidspunkt. Selvom dette princip helt sikkert vil fungere, når det kommer til at angribe en webserver, bliver det markant lettere, når zombie-computere i stedet for faktiske bemandede computere bruges.
Som du sikkert ved, er der masser af varianteraf malware og trojanere, der en gang på dit system ligger sovende og lejlighedsvis "ringer hjem" for instruktioner. En af disse instruktioner kan for eksempel være at sende gentagne anmodninger til Company Xs webserver kl. Så med en enkelt opdatering til hjemmeplacering af den respektive malware, kan en enkelt angriber øjeblikkeligt koordinere hundreder af tusinder af kompromitterede computere for at udføre et massivt DDoS-angreb.
Skønheden ved at bruge zombie-computere er ikke kun i dens effektivitet, men også i dens anonymitet, da angriberen faktisk ikke behøver at bruge deres computer overhovedet til at udføre angrebet.
SQL-injektionsangreb
Hvad er det?
Et "SQL injektion" (SQLI) angreb er en udnyttelseder drager fordel af dårlige webudviklingsteknikker og typisk kombineret med defekt databasesikkerhed. Resultatet af et vellykket angreb kan variere fra efterligning af en brugerkonto til et komplet kompromis af den respektive database eller server. I modsætning til et DDoS-angreb er et SQLI-angreb komplet og let at forebygge, hvis en webapplikation er passende programmeret.
Udførelse af angrebet
Hver gang du logger på et websted og indtaster dit brugernavn og din adgangskode, kan webapplikationen for at teste dine legitimationsoplysninger køre en forespørgsel som følgende:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Bemærk: strengværdier i en SQL-forespørgsel skal være indkapslet i enkelte citater, hvorfor de vises rundt om de brugerindtastede værdier.
Så kombinationen af det indtastede brugernavn(myuser) og adgangskode (mypass) skal matche en post i brugertabellen for at returnere en UserID. Hvis der ikke er nogen match, returneres ingen UserID, så loginoplysningerne er ugyldige. Mens en bestemt implementering kan variere, er mekanikken temmelig standard.
Så lad os nu se på en forespørgsel om skabelongodkendelse, som vi kan erstatte de værdier, som brugeren indtaster på webformularen:
VÆLG UserID FRA brugere HVOR Brugernavn = '[bruger]' OG adgangskode = '[pass]'
Ved første øjekast kan dette virke som enligetil og logisk trin til let validering af brugere, men hvis der udføres en simpel erstatning af de brugerindtastede værdier på denne skabelon, er den modtagelig for et SQLI-angreb.
Antag f.eks., At “myuser’–” er indtastet i brugernavnsfeltet, og “forkert pass” indtastes i adgangskoden. Ved hjælp af enkel substitution i vores skabelonforespørgsel, ville vi få dette:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
En nøgle til denne erklæring er inkluderingen af de to bindestreger (--). Dette er begynderkommentaren til SQL-udsagn, så alt der vises efter de to bindestreg (inklusive) ignoreres. I det væsentlige udføres ovennævnte forespørgsel af databasen som:
SELECT UserID FROM Users WHERE UserName='myuser'
Den iøjnefaldende undladelse her er manglen påadgangskontrol. Ved at inkludere de to streger som en del af brugerfeltet omgåede vi adgangskodekontrolbetingelsen fuldstændigt og var i stand til at logge ind som "myuser" uden at kende den respektive adgangskode. Denne handling med at manipulere forespørgslen for at producere utilsigtede resultater er et SQL-injektionsangreb.
Hvilken skade kan der gøres?
Et SQL-injektionsangreb er forårsaget af uagtsomhed oguansvarlig applikationskodning og er helt forebyggelig (som vi vil dække i et øjeblik), men omfanget af den skade, der kan udføres, afhænger af databaseopsætningen. For at en webapplikation skal kommunikere med backend-databasen, skal applikationen levere et login til databasen (bemærk, dette er anderledes end et bruger login på selve webstedet). Afhængigt af hvilke tilladelser webapplikationen kræver, kan denne respektive databasekonto kun kræve alt fra læse / skrive tilladelse i eksisterende tabeller til fuld databaseadgang. Hvis dette ikke er klart nu, skal et par eksempler hjælpe med at give en vis klarhed.
Baseret på eksemplet ovenfor kan du se det ved at indtaste f.eks. "youruser'--", "admin'--" eller ethvert andet brugernavn, kan vi øjeblikkeligt logge påwebstedet som denne bruger uden at kende adgangskoden. Når vi først er i systemet, ved det ikke, at vi faktisk ikke er den bruger, så vi har fuld adgang til den respektive konto. Databasetilladelser giver ikke et sikkerhedsnet til dette, fordi et websted typisk skal have mindst læse / skriveadgang til sin respektive database.
Lad os nu antage, at webstedet har fuld kontrol overdens respektive database, som giver mulighed for at slette poster, tilføje / fjerne tabeller, tilføje nye sikkerhedskonti osv. Det er vigtigt at bemærke, at nogle webapplikationer kunne have brug for denne type tilladelse, så det ikke automatisk er en dårlig ting, at fuld kontrol er bevilget.
Så for at illustrere den skade, der kan gøres i denne situation, bruger vi eksemplet, der er angivet i tegneserien ovenfor ved at indtaste følgende i brugernavnsfeltet: "Robert'; DROP TABLE Users;--". Efter simpel udskiftning bliver godkendelsesforespørgslen:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Bemærk: semikolonet er i en SQL-forespørgsel bruges til at betegne slutningen på en bestemt sætning og begyndelsen på en ny sætning.
Hvilket udføres af databasen som:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABEL Brugere
Så som sådan har vi brugt et SQLI-angreb til at slette hele brugertabellen.
Naturligvis kan meget værre gøres, afhængigt afSQL-tilladelser tilladt, angriberen kan ændre værdier, dumpe tabeller (eller hele databasen i sig selv) til en tekstfil, oprette nye login-konti eller endda kapre hele databaseinstallationen.
Forebyggelse af et SQL-injektionsangreb
Som vi nævnte flere gange tidligere, en SQLinjektionsangreb er let at forebygge. En af de vigtigste regler for webudvikling er, at du aldrig blindt har tillid til brugerinput, som vi gjorde, da vi udførte enkel substitution i vores skabelonforespørgsel ovenfor.
Et SQLI-angreb bliver let forhindret af, hvad der erkaldet at desinficere (eller undslippe) dine input. Sanitetsprocessen er faktisk ganske triviel, da alt i alt væsentligt er at håndtere ethvert inline-enkelt citat (‘) -tegn passende, således at de ikke kan bruges til for tidligt at afslutte en streng inde i en SQL-sætning.
Hvis du f.eks. Ønskede at slå “O’neil” op ien database, kunne du ikke bruge simpel erstatning, fordi det eneste citat efter O ville få strengen til at ende for tidligt. I stedet for desinficerer du den ved hjælp af den respektive databases flugtkarakter. Lad os antage, at flugtkarakteren for et enkelt, enkelt citat foretrækker hvert citat med et symbol. Så “O’neal” ville blive saneret som “O’neil”.
Denne enkle sanitetshandling forhindrer stort set et SQLI-angreb. For at illustrere, lad os revidere vores tidligere eksempler og se de resulterende forespørgsler, når brugerinputen er desinficeret.
myuser'-- / wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Da det eneste citat efter myuser er undgået (hvilket betyder, at det betragtes som en del af målværdien), vil databasen bogstaveligt søge efter brugernavnet på "myuser'--". Eftersom stregerne er inkluderet i strengværdien og ikke selve SQL-sætningen, vil de blive betragtet som en del af målværdien i stedet for at blive fortolket som en SQL-kommentar.
Robert'; DROP TABLE Users;-- / wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Ved blot at slippe fra det enkelte citat efter Robert, findes både semikolon og bindestreger i brugernavnet-søgestrengen, så databasen bogstaveligt vil søge efter "Robert'; DROP TABLE Users;--" i stedet for at udføre tabellen slet.
Sammenfattende
Mens webangreb udvikler sig og bliver meresofistikeret eller fokusere på et andet indgangspunkt, er det vigtigt at huske at beskytte mod afprøvede og sande angreb, der har været inspiration fra flere frit tilgængelige “hacker-værktøjer” designet til at udnytte dem.
Visse typer angreb, såsom DDoS, kan ikke værelet undgås, mens andre, såsom SQLI, kan. Imidlertid kan de skader, der kan udføres af disse typer angreb, spænde overalt fra ulemper til katastrofale afhængig af de forholdsregler, der er truffet.
