Även om du bara har löst följt händelserna i hackergrupperna Anonymous och LulzSec har du säkert hört talas om webbplatser och Tjänsterna 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 handbok 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 "distribuerad nekad tjänst" eller DDoS) attack 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 enkelt upp och stängs 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 förklaras bäst av 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. 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-verksamhet 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 förfrågan, är denna typ av attack vanligtvis mycket effektiv.

Genomföra attacken

På grund av "brute kraften "av en DDoS-attack, 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 ringa 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 zombidatorer används istället för faktiska bemannade datorer.

Som du säkert vet finns det många varianter av malware och trojaner som , en gång på ditt system, ligga 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. Så med en enda uppdatering till respektive malwares hemort kan en enskild angripare omedelbart samordna hundratusentals kompromisserade datorer för att utföra ett massivt DDoS-angrepp.

Det är inte bara effektivt att använda zombie-datorer, utan också

SQL Injection Attack

Vad är det?

En SQL-inmatning är en anknytning till SQL-injektion utnyttja som utnyttjar fattiga webbutvecklingstekniker och, i kombination med, felaktig databas sä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 DDoS-attacker kan en SQLI-attack helt och enkelt förebyggas 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 din legitimationsuppgifter webbapplikationen kan leda till en fråga som följande:

SELECT UserID FROM Användare WHERE UserName = "myuser" OCH Lösenord = "mypass";

Obs! Strängvärden i en SQL-fråga måste bifogas enskilda citat. Därför visas de runt användarens angivna värden.

Så kombinationen av det inmatade användarnamnet (myuser) och lösenordet (mypass) måste matcha en post i Användar tabellen för att en UserID ska returneras. Om det inte finns någon matchning returneras ingen UserID så inloggningsuppgifterna är ogiltiga. Medan ett visst genomförande kan skilja sig, är mekaniken ganska standard. Så här ska vi nu 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 verifiera användare, men om en enkel substitution av de användardefinierade värdena utförs på denna mall är det mottaglig för en SQLI-attack.

Anta 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å streck

(-). 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 brutna bortloppet 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. Den här åtgärden att manipulera frågan om att skapa oavsiktliga resultat är en SQL-injektionsattack.

Vilken skada kan göras?

En SQL-injektionsattack orsakas av oaktsam och ansvarsfull applikationskodning och är fullständigt förebyggbar (som vi kommer att täcka in 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 med att ge tydlighet.

På grundval av ovanstående exempel kan du se det genom att skriva in

"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 måste ha åtminstone läs / skrivåtkomst till sin respektive databas.Låt oss nu anta att webbplatsen har full kontroll över sin respektive databas som ger möjligheten att radera poster, lägga till / ta bort tabeller, lägg 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. 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 Användare; - ".

Efter enkel substitution blir autentiseringsfrågan:SELECT UserID FROM Users 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 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 ä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 enkla substitutioner i vår mallfråga ovan.

En SQLI-attack är lätt försvagad av vad som heter 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 för tidigt avsluta en sträng inuti ett SQL-uttalande.

Om du till exempel vill Lookup "O'neil" i en databas, du kunde 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 FRÅN Användare WHERE UserName = " myuser "-" och lösenord = "wrongpass" Eftersom det enda citatet efter myuser är undanröjt (vilket betyder att det anses vara en del av målvärdet), söker databasen bokstavligen 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 : SELECT UserID 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 Användare; - "

i stället för att utföra tabellen raderas.I sammanfattningMedan webattacker utvecklas och blir mer sofistikerade eller fokuserar på en annan punkt, är det viktigt att komma ihåg att skydda mot attacker som har inspirerats av flera fritt tillgängliga "hackerverktyg" som är utformade för att utnyttja dem.

Vissa typer 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 obehag till katastrof beroende på de försiktighetsåtgärder som vidtagits.

Hur stänger du av en Windows-dator som saknar fjärrskrivbordsstöd på ett hemnätverk?

Att få ditt hemnätverk inrättat för enkel användning är ett mycket önskvärt mål att uppnå, men vad gör du när datorn som du vill använda som mediaserver saknar fjärrstöd för skrivbordet? Dagens SuperUser Q & A-post har några användbara råd till en frustrerad läsare. Dagens Frågesvar-session hämtar oss med SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

(how-to)

Varför skulle en SSD internt kryptera data utan lösenord?

Medan många aktivt väljer att kryptera sina data, kan andra bli förvånad över att deras nuvarande enhet gör det automatiskt utan att mata in från dem. Varför är det så? Dagens SuperUser Q & A-inlägg har svar på en nyfiken läsarens fråga. Dagens Frågor och svar sessions kommer till vår tjänst med SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

(how-to)