Även om du bara löst har följt händelserna i hackargrupperna Anonymous och LulzSec, har du förmodligen hört talas om webbplatser och tjänster som hackats, som de ökända Sony-hackarna. Har du någonsin undrat hur de gör det?
Det finns ett antal verktyg och tekniker som dessa grupper använder, och även om vi inte försöker ge dig en manual för att göra det själv är det bra att förstå vad som händer. Två av de attacker som du konsekvent hör om dem med är “(Distribuerad) Denial of Service” (DDoS) och “SQL Injections” (SQLI). Så här fungerar de.
Bild av xkcd
Denial of Service Attack
Vad är det?
En ”denial of service” (ibland kallad “distribution denial of service” eller DDoS) inträffar när ett system, i detta fall en webbserver, tar emot så många förfrågningar samtidigt att serverresurserna är överbelastade, systemet helt enkelt låser och stängs av. Målet och resultatet av en framgångsrik DDoS-attack är att webbplatserna på målservern inte är tillgängliga för legitima trafikförfrågningar.
Hur fungerar det?
Logistiken för en DDoS-attack kan förklaras bäst med ett exempel.
Föreställ dig att en miljon människor (angriparna) träffas i syfte att hindra företag X: s verksamhet genom att ta bort deras callcenter. Angriparna samordnar så att de alla tisdag klockan 9.00 ringer till företagets telefonnummer. Troligtvis kommer inte företagets telefonsystem att kunna hantera en miljon samtal på en gång, så alla inkommande linjer kommer att bindas av angriparna. Resultatet är att legitima kundsamtal (dvs. de som inte är angriparna) inte kommer igenom eftersom telefonsystemet är bundet och hanterar samtalen från angriparna. Så i huvudsak tappar företag X potentiellt affärer på grund av att legitima förfrågningar inte kan komma igenom.
En DDoS-attack på en webbserver fungerar exakt på samma sätt. Eftersom det praktiskt taget inte finns något sätt att veta vilken trafik som kommer från legitima förfrågningar kontra angripare tills webbservern behandlar begäran, är denna typ av attack vanligtvis mycket effektiv.
Utför attacken
På grund av den ”brute force” karaktären hos en DDoS-attack måste du ha massor av datorer alla samordnade för att attackera samtidigt. Om vi återgår till vårt callcenter-exempel, skulle detta kräva att alla angripare vet att de ringer klockan 9 och faktiskt ringer vid den tiden. Även om denna princip verkligen kommer att fungera när det gäller att attackera en webbserver, blir det betydligt lättare när zombiedatorer används istället för faktiska bemannade datorer.
Som du säkert vet finns det många varianter av skadlig kod och trojaner som, en gång på ditt system, ligger vilande och ibland “ringer hem” för instruktioner. En av dessa instruktioner kan till exempel vara att skicka upprepade förfrågningar till Company Xs webbserver klockan 9. Så med en enda uppdatering av hemplaceringen för respektive skadlig kod kan en enda angripare omedelbart samordna hundratusentals komprometterade datorer för att utföra en massiv DDoS-attack.
Skönheten i att använda zombiedatorer är inte bara i dess effektivitet utan också i dess anonymitet, eftersom angriparen faktiskt inte behöver använda sin dator alls för att utföra attacken.
SQL Injection Attack
Vad är det?
En "SQL-injektion" (SQLI) -attack är ett utnyttjande som utnyttjar dålig webbutvecklingsteknik och, vanligtvis i kombination med, felaktig databassäkerhet. Resultatet av en lyckad attack kan sträcka sig från att imitera ett användarkonto till en fullständig kompromiss mellan respektive databas eller server. Till skillnad från en DDoS-attack kan en SQLI-attack helt och hållet förebyggas om en webbapplikation är korrekt programmerad.
Utför attacken
När du loggar in på en webbplats och anger ditt användarnamn och lösenord kan webbapplikationen köra en fråga för att testa dina uppgifter:
VÄLJ användar-ID från användare VAR användarnamn = 'minanvändare' OCH lösenord = 'mypass';
Obs! Strängvärden i en SQL-fråga måste bifogas i enstaka citat, varför de visas runt de användarinmatade värdena.
Så kombinationen av det angivna användarnamnet (myuser) och lösenordet (mypass) måste matcha en post i tabellen Användare för att ett UserID ska returneras. Om det inte finns någon matchning returneras inget användar-ID så inloggningsuppgifterna är ogiltiga. Medan en viss implementering kan skilja sig från är mekaniken ganska standard.
Så nu ska vi titta på en mallautentiseringsfråga som vi kan ersätta de värden som användaren anger på webbformuläret:
VÄLJ användarID FRA användare VAR användarnamn = '[user]' OCH lösenord = '[pass]'
Vid första anblicken kan detta verka som ett enkelt och logiskt steg för att enkelt validera användare, men om en enkel ersättning av de användarinmatade värdena utförs i den här mallen är den mottaglig för en SQLI-attack.
Antag till exempel att “myuser’–” anges i användarnamnsfältet och ”felpass” anges i lösenordet. Med hjälp av enkel ersättning i vår mallfråga skulle vi få det här:
VÄLJ UserID FRA användare WHERE UserName = 'myuser' - 'AND Password =' wrongpass '
En nyckel till detta uttalande är inkluderingen av de två streckarna
(--)
. Detta är startkommentar-token för SQL-uttalanden, så allt som visas efter de två streckarna (inklusive) ignoreras. I huvudsak körs ovanstående fråga av databasen som:
VÄLJ UserID FRA användare WHERE UserName = 'myuser'
Den uppenbara utelämnandet här är bristen på lösenordskontrollen. Genom att inkludera de två streckarna som en del av användarfältet kringgick vi helt lösenordskontrollvillkoren och kunde logga in som “myuser” utan att känna till respektive lösenord. Denna handling att manipulera frågan för att producera oavsiktliga resultat är en SQL-injektionsattack.
Vilken skada kan göras?
En SQL-injektionsattack orsakas av vårdslös och oansvarig applikationskodning och är helt förebyggbar (vilket vi kommer att täcka om ett ögonblick), men omfattningen av skadan som kan göras beror på databasinställningen. För att en webbapplikation ska kunna kommunicera med backend-databasen måste applikationen tillhandahålla en inloggning till databasen (notera, detta är annorlunda än en användarinloggning till själva webbplatsen). Beroende på vilka behörigheter webbapplikationen kräver, kan detta respektive databaskonto kräva allt från läs- / skrivbehörighet i befintliga tabeller till full databasåtkomst. Om detta inte är klart nu bör några exempel hjälpa till att ge klarhet.
Baserat på ovanstående exempel kan du se att genom att t.ex. ange
"dinanvändare" - "," admin "-"
eller något annat användarnamn kan vi omedelbart logga in på webbplatsen som den användaren utan att veta lösenordet. När vi väl är inne i systemet vet vi inte att vi egentligen är den användaren, så vi har full tillgång till respektive konto. Databasbehörigheter tillhandahåller inte ett skyddsnät för detta eftersom en webbplats vanligtvis måste ha åtminstone läs- / skrivåtkomst till respektive databas.
Låt oss nu anta att webbplatsen har full kontroll över sin respektive databas som ger möjlighet att ta bort poster, lägga till / ta bort tabeller, lägga till nya säkerhetskonton etc. Det är viktigt att notera att vissa webbapplikationer kan behöva denna typ av tillstånd så att det är inte automatiskt en dålig sak att full kontroll beviljas.
Så för att illustrera skadorna som kan göras i denna situation kommer vi att använda exemplet i serien ovan genom att ange följande i användarnamnsfältet:
"Robert '; DROP TABLE Users; -".
Efter enkel ersättning blir autentiseringsfrågan:
VÄLJ UserID FRA användare WHERE UserName = 'Robert'; DROPTABELL Användare; - 'OCH Lösenord =' felpass '
Obs: semikolonet finns i en SQL-fråga används för att beteckna slutet på ett visst uttalande och början på ett nytt uttalande.
Som körs av databasen som:
VÄLJ UserID FRA användare WHERE UserName = 'Robert'DROP TABLE Användare
Så precis så har vi använt en SQLI-attack för att ta bort hela användartabellen.
Naturligtvis kan mycket sämre göras eftersom angriparen, beroende på de tillåtna SQL-behörigheterna, kan ändra värden, dumpa tabeller (eller hela databasen) till en textfil, skapa nya inloggningskonton eller till och med kapa hela databasinstallationen.
Förhindra en SQL-injektionsattack
Som vi nämnde flera gånger tidigare är en SQL-injektionsattack lätt att förebygga. En av de viktigaste reglerna för webbutveckling är att du aldrig blint litar på användarinmatningen som vi gjorde när vi utförde en enkel ersättning i vår mallfråga ovan.
En SQLI-attack hindras lätt av det som kallas att desinficera (eller komma undan) dina ingångar. Saneringsprocessen är faktiskt ganska trivial eftersom allt det i huvudsak gör är att hantera alla inbyggda enskilda citattecken (‘) på lämpligt sätt så att de inte kan användas för att i förtid avsluta en sträng inuti ett SQL-uttalande.
Om du till exempel vill slå upp "O'neil" i en databas, kan du inte använda enkel ersättning eftersom det enda citatet efter O skulle orsaka att strängen slutar för tidigt. Istället sanerar du det med hjälp av respektive databas flyktecken. Låt oss anta att flyktecknet för ett inbyggt enstaka offert är före varje citat med en \ symbol. Så "O'neal" skulle saneras som "O \ 'neil".
Denna enkla sanitetshandling förhindrar i stort sett en SQLI-attack. För att illustrera, låt oss granska våra tidigare exempel och se de resulterande frågorna när användarinmatningen är sanerad.
myuser '-
/
felpass
:
VÄLJ UserID FRA användare WHERE UserName = 'myuser \' - 'AND Password =' wrongpass '
Eftersom det enskilda offertet efter att minanvändare har undkommit (vilket betyder att det anses vara en del av målvärdet), kommer databasen bokstavligen att söka efter UserName av
"myuser" - ".
Dessutom, eftersom bindestreck ingår i strängvärdet och inte i själva SQL-satsen, kommer de att betraktas som en del av målvärdet istället för att tolkas som en SQL-kommentar.
Robert '; DROP TABLE Användare; -
/
felpass
:
VÄLJ UserID FRA användare WHERE UserName = 'Robert \'; DROPTABELL Användare; - 'OCH Lösenord =' felpass '
Genom att helt enkelt fly från den enskilda offerten efter Robert finns både semikolon och bindestreck i söksträngen UserName så att databasen bokstavligen söker efter
"Robert"; DROP TABLE-användare; - "
istället för att köra tabellen ta bort.
Sammanfattningsvis
Medan webbattacker utvecklas och blir mer sofistikerade eller fokuserar på en annan inträdesplats, är det viktigt att komma ihåg att skydda mot beprövade och sanna attacker som har varit inspiration för flera fritt tillgängliga "hackerverktyg" som är utformade för att utnyttja dem.
Vissa typer av attacker, som DDoS, kan inte lätt undvikas medan andra, som SQLI, kan. Skadorna som kan göras av dessa typer av attacker kan dock variera var som helst från ett besvär till katastrofalt beroende på de försiktighetsåtgärder som vidtagits.
