Hur Hackers tar över webbplatser med SQL Injection och DDoS
Även om du bara har löst följt händelserna i hackergrupperna Anonymous och LulzSec har du säkert hört att webbplatser och tjänster hackas, 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 medan vi inte försöker ge dig en manual för att göra det själv, är det användbart att förstå vad som händer. Två av de attacker som du konsekvent hör om dem använder är "(Distributed) Denial of Service" (DDoS) och "SQL Injections" (SQLI). Så här fungerar de.
Bild av xkcd
Denial of Service Attack
Vad är det?
En "nekad tjänst" (ibland kallad "distributed 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 som serverns resurser överbelastas, låser systemet helt enkelt upp och stänger av. Målet och resultatet av ett lyckat DDoS-angrepp är att webbplatser på målservern inte är tillgängliga för legitima trafikförfrågningar.
Hur fungerar det?
Logistiken för DDoS-attacken kan bäst förklaras med ett exempel.
Tänk dig att en miljon människor (angriparna) kommer ihop med målet att hindra företag X: s verksamhet genom att ta ner sitt callcenter. Attackerna samordnar så att de tisdag klockan 9 kommer alla att ringa till företag Xs telefonnummer. Mest troligt kommer Company Xs telefonsystem inte att kunna hantera en miljon samtal på en gång så alla inkommande linjer kommer att bindas upp av angriparna. Resultatet är att legitima kundsamtal (det vill säga de som inte är angriparna) inte kommer igenom, eftersom telefonsystemet är bundet upp och hanterar samtal från attackerna. Så i huvudsak saknar företaget X potentiellt förlust på grund av att de legitima förfrågningarna inte kan komma igenom.
En DDoS-attack på en webbserver fungerar exakt på samma sätt. Eftersom det finns praktiskt taget inget sätt att veta vilken trafik som kommer från legitima förfrågningar mot angripare tills webbservern behandlar begäran, är denna typ av attack typiskt mycket effektiv.
Genomföra attacken
På grund av DDoS-attackens brutna kraft måste du ha massor av datorer som alla samordnas för att attackera samtidigt. Genom att ompröva vårt callcenter-exempel skulle detta kräva att alla angripare både vet att ringa klockan 9 och faktiskt ringer vid den tiden. Medan denna princip verkligen kommer att fungera när det gäller att attackera en webbserver, blir det betydligt lättare när zombidatorer, i stället för faktiska bemannade datorer, utnyttjas.
Som du säkert vet finns det många varianter av malware och trojaner som, en gång på ditt system, ligger vilande och ibland "ringa hem" för instruktioner. En av dessa anvisningar kan till exempel vara att skicka upprepade förfrågningar till Company Xs webbserver klockan 9 AM. Med en enda uppdatering till respektive malwares hemort kan en enskild angripare direkt samordna hundratusentals komprometterade datorer för att utföra ett massivt DDoS-angrepp.
Skönheten att utnyttja zombie-datorer är inte bara i sin effektivitet utan också i dess anonymitet eftersom angriparen inte faktiskt behöver använda sin dator alls för att utföra attacken.
SQL Injection Attack
Vad är det?
En SQL-inmatning (SQL injection) är ett utnyttjande som drar nytta av dålig webbutvecklingsteknik och, i kombination med, felaktig databas säkerhet. Resultatet av en framgångsrik attack kan sträcka sig från att ersätta ett användarkonto till en komplett kompromiss av respektive databas eller server. Till skillnad från ett DDoS-angrepp är en SQLI-attack helt och enkelt förebyggbar om en webapplikation är korrekt programmerad.
Genomföra attacken
När du loggar in på en webbplats och anger ditt användarnamn och lösenord, för att testa dina uppgifter, kan webapplikationen leda en fråga som följande:
VÄLJ UserID FROM Användare WHERE UserName = "myuser" OCH Lösenord = "mypass";
Obs! Strängvärdena i en SQL-fråga måste bifogas enkla citattecken, varför de visas runt de användardefinierade värdena.
Så kombinationen av det inmatade användarnamnet (myuser) och lösenordet (mypass) måste matcha en post i användartabellen för att en UserID ska returneras. Om det inte finns någon match returneras ingen UserID så inloggningsuppgifterna är ogiltiga. Medan en viss implementering kan skilja sig, är mekaniken ganska standard.
Så nu ska vi titta på en autentiseringsfråga som vi kan ersätta värden användaren anger på webbformuläret:
SELECT UserID FROM Users WHERE UserName = "[användare]" och lösenord = "[passera]"
Vid första anblicken kan det verka som ett enkelt och logiskt steg för att enkelt kunna validera användare, men om en enkel substitution av de användardefinierade värdena utförs på denna mall, är den känslig för en SQLI-attack.
Antag till exempel att "myuser" - "anges i användarnamnet och" wrongpass "är inmatat i lösenordet. Med hjälp av enkel substitution i vår mallfråga skulle vi få det här:
SELECT UserID FROM Användare WHERE UserName = "myuser" - 'OCH Lösenord = "wrongpass"
En nyckel till detta uttalande är införandet av de två bindestreckarna (-). Det här är början på kommentarsignalen för SQL-satser, så allt som visas efter de två streck (inklusive) kommer att ignoreras. I huvudsak utförs ovannämnda fråga av databasen som:
SELECT UserID FROM Användare WHERE UserName = "myuser"
Den skarpa utelämnandet här är bristen på lösenordskontrollen. Genom att inkludera de två streckfönstren som en del av användarfältet, gick vi helt igenom lösenkontrolltillståndet 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 oaktsam och oansvarig applikationskodning och är fullständigt förebyggbar (vilken vi kommer att täcka på ett ögonblick), men omfattningen av skadan som kan göras beror på databasinstallationen. För att en webbapplikation ska kunna kommunicera med backenddatabasen måste ansökan tillhandahålla en inloggning till databasen (anmärkning, detta skiljer sig från användarens inloggning till webbplatsen). Beroende på vilka behörigheter webbapplikationen kräver kan det här databaskontot kräva allt från läs- / skrivbehörighet i befintliga tabeller endast till fullständig databasåtkomst. Om detta inte är klart nu, bör några exempel hjälpa till att ge tydlighet.
Baserat på ovanstående exempel kan du se det genom att skriva in, till exempel, "youruser" - "," admin "-" eller något annat användarnamn, kan vi direkt logga in på webbplatsen som den användaren utan att veta lösenordet. När vi är i systemet vet vi inte att vi inte är den användaren så vi har full tillgång till respektive konto. Databasbehörigheter ger inte ett säkerhetsnät för detta eftersom en webbplats måste ha åtminstone läs- / skrivåtkomst till sin respektive databas.
Låt oss nu anta att webbplatsen har fullständig kontroll över sin respektive databas som ger möjlighet att radera poster, lägga till / ta bort tabeller, lägga till nya säkerhetskonton etc. Det är viktigt att notera att vissa webbprogram kan behöva denna typ av behörighet så det Det är inte automatiskt en dålig sak att full kontroll beviljas.
För att illustrera skadorna som kan göras i denna situation använder vi exemplet i komiken ovan genom att ange följande i användarnamnet fält: "Robert"; DROP TABLE Användare; - ". Efter enkel substitution blir autentiseringsfrågan:
VÄLJ UserID FROM Användare WHERE UserName = "Robert"; DROP TABLE Användare; - 'OCH Lösenord = "wrongpass"
Obs! Semikolonen är i en SQL-fråga används för att indikera slutet på ett visst uttalande och början på ett nytt uttalande.
Vilken som körs av databasen som:
SELECT UserID FROM Användare WHERE UserName = "Robert"DROP TABLE Användare
Så precis som det har vi använt en SQLI-attack för att ta bort hela användar tabellen.
Självklart kan mycket värre göras eftersom, beroende på tillåtna SQL-behörigheter, kan angriparen ändra värden, dumpa tabeller (eller hela databasen själv) till en textfil, skapa nya inloggningskonton eller kapa hela databasinstallationen.
Förhindra en SQL-injektionsattack
Som vi nämnde flera gånger tidigare är det lätt att förebygga en SQL-injektionsattack. En av de kardinala reglerna för webbutveckling är att du aldrig stolt litar på användarinmatning som vi gjorde när vi utförde enkel substitution i vår mallfråga ovan.
En SQLI-angrepp motverkas enkelt av vad som kallas sanitizing (eller escaping) dina ingångar. Sanitiseringsprocessen är faktiskt ganska trivial eftersom allt som i allt väsentligt hanterar några inline-citat (') tecken på ett lämpligt sätt så att de inte kan användas för att tidigt avsluta en sträng inuti ett SQL-uttalande.
Om du till exempel vill söka "O'neil" i en databas, kan du inte använda enkel substitution eftersom det enda citatet efter O skulle få strängen att sluta tidigt. Istället sanerar du det med hjälp av respektive databas flykttecken. Låt oss anta att escape-karaktären för ett inline-citat är prefacing varje citat med en \ -symbol. Så "O'neal" skulle saneras som "O \ 'neil".
Denna enkla sanitetsåtgärd hindrar ganska mycket en SQLI-attack. För att illustrera, låt oss se våra tidigare exempel och se de resulterande frågorna när användarinmatningen är sanitiserad.
myuser'-- / wrongpass:
SELECT UserID FROM Användare WHERE UserName = "myuser \" - 'OCH Lösenord = "wrongpass"
Eftersom det enda citatet efter myuser är flyktat (vilket betyder att det anses vara en del av målvärdet), söker databasen bokstavligen efter användarnamnet av "Myuser" -. Dessutom, eftersom streckarna ingår i strängvärdet och inte 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;-- / wrongpass:
VÄLJ UserID FROM Användare WHERE UserName = "Robert \"; DROP TABLE Användare; - 'OCH Lösenord = "wrongpass"
Genom att helt enkelt flyga det enkla citatet efter Robert finns både semikolon och bindestreck i användarnamnssökningssträngen så databasen kommer bokstavligen att söka efter "Robert"; DROP TABLE Användare; - " istället för att exekvera tabellen raderas.
Sammanfattningsvis
Medan webbattacker utvecklas och blir mer sofistikerade eller fokuserar på en annan punkt, är det viktigt att komma ihåg att skydda mot försök och sanna attacker som har inspirerats av 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. Den skada som kan utföras av dessa typer av attacker kan emellertid variera från ett besvär till katastrof beroende på de försiktighetsåtgärder som vidtagits.
