26Aug
Ä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 är överbelastade låser systemet helt enkeltupp och stänger avMå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( attackerna) kommer ihop med målet att hindra företag X: s verksamhet genom att ta ner sitt callcenter. Anfallarna samordnar så att de tisdag klockan 9 kommer alla att ringa till företagets telefonnummer. Mest sannolikt kommer Company Xs telefonsystem inte att kunna hantera en miljon samtal på en gång så alla inkommande linjer kommer att binds upp av angriparna. Resultatet är att legitima kundsamtal( det vill säga de som inte är angriparna) inte kommer igenom, eftersom telefonsystemet är bunden med hanteringen av 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 hämtas från legitima förfrågningar mot angripare tills webbservern behandlar begäran, är denna typ av attack vanligtvis mycket effektiv.
Genomföra attacken
På grund av DDoS-attackens brutna kraft måste du ha många 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 ringa 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, istä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 "telefon 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.Så med en enda uppdatering till respektive malwares hemort kan en enda angripare direkt samordna hundratusentals kompromisserade 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 behöver använda sin dator alls för att utföra attacken.
SQL Injection Attack
Vad är det?
En "SQL injection" -attack( SQLI) -attack är ett utnyttjande som drar nytta av dålig webbutvecklingsteknik och, i kombination med felaktig databasssäkerhet. Resultatet av en framgångsrik attack kan sträcka sig från att utgöra 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 referenser kan webbprogrammet leda en fråga som följande:
SELECT UserID FROM Användare WHERE UserName = 'myuser' och lösenord= 'mypass';
Obs! Strängvärdena i en SQL-fråga måste bifogas enskilda citat, varför de visas runt de användarinställda 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 matchning 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ärdena användaren anger på webbformuläret:
SELECT UserID FROM Användare WHERE UserName = '[user]' och lösenord = '[passera]'
Vid första anblickenkan 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 att "myuser" - "anges i användarnamnet fält och" wrongpass "anges 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å streckfilerna( -).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 klara 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ösenordskontrollen 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.
Vilka skador 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 webapplikationen 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 en viss klarhet.
Baserat på ovanstående exempel kan du se att genom att ange 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 faktiskt inte är den användaren så vi har full tillgång till respektive konto. Databasbehörigheter kommer inte att ge ett säkerhetsnät för detta eftersom en webbplats normalt 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 är inte automatiskt en dålig sak att full kontroll beviljas.
För att illustrera skador som kan göras i den här situationen använder vi exemplet i komiken ovan genom att ange följande i användarnamnet fält: "Robert"; DROP TABLE Users; - ".Efter enkel substitution blir autentiseringsfrågan:
SELECT 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.
Som utfö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 radera hela användartabellen.
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 kan en SQL-injektionsattack lätt förebyggas. 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 är lätt motverkad 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 ".
Den här enkla sanitetshandlingen förhindrar 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 "- / felpass :
VÄLJ Användarnamn FRÅN Användare WHERE UserName = 'myuser \' - 'OCH Lösenord =' wrongpass '
Eftersom det enda citatet efter myuser är flyktigt( vilket betyder att det anses vara en del av måletvärde), kommer databasen bokstavligen att söka efter användarnamnet för "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 Användarnamn FRÅN 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 Users;- "istället för att exekvera tabellen raderas.
I sammanfattning
Medan webattacker 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 enkelt undvikas medan andra, som SQLI, kan. Skador som kan utföras av dessa typer av attacker kan emellertid variera från obehag till katastrof beroende på de försiktighetsåtgärder som vidtagits.
