Zelfs als je de gebeurtenissen van de hackergroepen Anonymous en LulzSec maar losjes hebt gevolgd, heb je waarschijnlijk gehoord dat websites en services worden gehackt, zoals de beruchte Sony-hacks. Heb je je ooit afgevraagd hoe ze het doen?
Er zijn een aantal tools en technieken die deze groepen gebruiken, en hoewel we niet proberen u een handleiding te geven om dit zelf te doen, is het handig om te begrijpen wat er aan de hand is. Twee van de aanvallen die u consequent over hen hoort gebruiken, zijn "(Distributed) Denial of Service" (DDoS) en "SQL Injections" (SQLI). Hier is hoe ze werken.
Afbeelding door xkcd
Denial of Service-aanval
Wat is het?
Een 'denial of service'-aanval (ook wel een' gedistribueerde denial of service 'of DDoS genoemd) -aanval vindt plaats wanneer een systeem, in dit geval een webserver, zoveel verzoeken tegelijk ontvangt dat de serverbronnen overbelast raken dat het systeem gewoon vastloopt en wordt afgesloten. Het doel en resultaat van een succesvolle DDoS-aanval is dat de websites op de doelserver niet beschikbaar zijn voor legitieme verkeersverzoeken.
Hoe werkt het?
De logistiek van een DDoS-aanval kan het beste worden verklaard door een voorbeeld.
Stel je voor dat een miljoen mensen (de aanvallers) samenkomen met als doel de zaken van Bedrijf X te belemmeren door hun callcenter neer te halen. De aanvallers coördineren zodat ze dinsdag om 9 uur allemaal het telefoonnummer van bedrijf X bellen. Hoogstwaarschijnlijk kan het telefoonsysteem van bedrijf X geen miljoen oproepen tegelijk afhandelen, dus alle inkomende lijnen zullen door de aanvallers worden vastgebonden. Het resultaat is dat legitieme klantoproepen (d.w.z. degenen die niet de aanvallers zijn) niet doorkomen omdat het telefoonsysteem vastzit aan het afhandelen van de oproepen van de aanvallers. Dus in wezen verliest bedrijf X mogelijk zaken omdat de legitieme verzoeken er niet doorheen kunnen komen.
Een DDoS-aanval op een webserver werkt op precies dezelfde manier. Omdat er vrijwel geen manier is om te weten welk verkeer afkomstig is van legitieme verzoeken versus aanvallers totdat de webserver het verzoek verwerkt, is dit type aanval doorgaans erg effectief.
De aanval uitvoeren
Vanwege de "brute force" aard van een DDoS-aanval, moet u veel computers hebben die allemaal gecoördineerd zijn om tegelijkertijd aan te vallen. Als we ons callcenter-voorbeeld opnieuw bekijken, zouden alle aanvallers moeten weten dat ze om 9 uur 's ochtends moeten bellen en ook daadwerkelijk op dat moment moeten bellen. Hoewel dit principe zeker zal werken als het gaat om het aanvallen van een webserver, wordt het aanzienlijk gemakkelijker wanneer zombiecomputers worden gebruikt in plaats van echte bemande computers.
Zoals u waarschijnlijk weet, zijn er veel varianten van malware en Trojaanse paarden die, eenmaal op uw systeem, inactief blijven en af en toe "naar huis bellen" voor instructies. Een van deze instructies zou bijvoorbeeld kunnen zijn om om 09.00 uur herhaalde verzoeken naar de webserver van bedrijf X te sturen. Dus met een enkele update van de thuislocatie van de respectievelijke malware, kan een enkele aanvaller onmiddellijk honderdduizenden gecompromitteerde computers coördineren om een enorme DDoS-aanval uit te voeren.
Het mooie van het gebruik van zombiecomputers is niet alleen de effectiviteit, maar ook de anonimiteit, aangezien de aanvaller zijn computer helemaal niet hoeft te gebruiken om de aanval uit te voeren.
SQL-injectie-aanval
Wat is het?
Een "SQL-injectie" (SQLI) -aanval is een exploit die profiteert van slechte webontwikkelingstechnieken en, doorgaans gecombineerd met, gebrekkige databasebeveiliging. Het resultaat van een succesvolle aanval kan variëren van het zich voordoen als een gebruikersaccount tot een volledige inbreuk op de respectieve database of server. In tegenstelling tot een DDoS-aanval is een SQLI-aanval volledig en gemakkelijk te voorkomen als een webapplicatie op de juiste manier is geprogrammeerd.
De aanval uitvoeren
Elke keer dat u inlogt op een website en uw gebruikersnaam en wachtwoord invoert, kan de webtoepassing een zoekopdracht uitvoeren zoals de volgende om uw inloggegevens te testen:
SELECTEER Gebruikers-ID VAN Gebruikers WAAR UserName = 'mijngebruiker' EN Wachtwoord = 'mijnpas';
Opmerking: tekenreekswaarden in een SQL-query moeten tussen enkele aanhalingstekens staan, daarom verschijnen ze rond de door de gebruiker ingevoerde waarden.
Dus de combinatie van de ingevoerde gebruikersnaam (mijngebruiker) en het wachtwoord (mijnpas) moet overeenkomen met een invoer in de tabel Gebruikers om een gebruikers-ID terug te geven. Als er geen overeenkomst is, wordt er geen gebruikers-ID geretourneerd, zodat de inloggegevens ongeldig zijn. Hoewel een bepaalde implementatie kan verschillen, zijn de mechanica vrij standaard.
Laten we nu eens kijken naar een sjabloonverificatiequery die we kunnen vervangen door de waarden die de gebruiker op het webformulier invoert:
SELECTEER Gebruikers-ID VAN Gebruikers WAAR UserName = '[user] ’EN Wachtwoord =' [pass]’
Op het eerste gezicht lijkt dit misschien een eenvoudige en logische stap om gebruikers gemakkelijk te valideren, maar als een eenvoudige vervanging van de door de gebruiker ingevoerde waarden wordt uitgevoerd op deze sjabloon, is het vatbaar voor een SQLI-aanval.
Stel bijvoorbeeld dat ‘mijngebruiker’–’ wordt ingevoerd in het gebruikersnaamveld en ‘wrongpass’ in het wachtwoord. Door eenvoudige vervanging in onze sjabloonquery te gebruiken, zouden we dit krijgen:
SELECTEER Gebruikers-ID VAN Gebruikers WAAR UserName = 'myuser' - 'AND Password =' wrongpass '
Een sleutel tot deze verklaring is de opname van de twee streepjes
(--)
. Dit is het begincommentaar-token voor SQL-instructies, dus alles wat verschijnt na de twee streepjes (inclusief) wordt genegeerd. In wezen wordt de bovenstaande query uitgevoerd door de database als:
SELECTEER Gebruikers-ID VAN Gebruikers WAAR UserName = 'myuser'
De flagrante omissie hier is het ontbreken van de wachtwoordcontrole. Door de twee streepjes op te nemen als onderdeel van het gebruikersveld, hebben we de voorwaarde voor wachtwoordcontrole volledig omzeild en konden we inloggen als "mijngebruiker" zonder het respectieve wachtwoord te kennen. Deze handeling van het manipuleren van de query om onbedoelde resultaten te produceren, is een SQL-injectie-aanval.
Welke schade kan worden aangericht?
Een SQL-injectie-aanval wordt veroorzaakt door nalatige en onverantwoordelijke applicatiecodering en is volledig te voorkomen (wat we zo meteen zullen behandelen), maar de omvang van de schade die kan worden aangericht, is afhankelijk van de database-instellingen. Om een webtoepassing te laten communiceren met de backend-database, moet de toepassing een login voor de database opgeven (let op, dit is anders dan een gebruikersaanmelding op de website zelf). Afhankelijk van welke machtigingen de webtoepassing vereist, kan dit respectieve databaseaccount alles vereisen, van alleen lees- / schrijfrechten in bestaande tabellen tot volledige databasetoegang. Als dit nu niet duidelijk is, zouden een paar voorbeelden enige duidelijkheid moeten bieden.
Aan de hand van het bovenstaande voorbeeld kunt u dat zien door bijvoorbeeld
"uwgebruiker '-", "admin' -"
of een andere gebruikersnaam, kunnen we onmiddellijk inloggen op de site als die gebruiker zonder het wachtwoord te kennen. Als we eenmaal in het systeem zijn, weten we niet dat we niet echt die gebruiker zijn, dus we hebben volledige toegang tot het respectieve account. Database-machtigingen bieden hiervoor geen vangnet, omdat een website doorgaans ten minste lees- / schrijftoegang tot de desbetreffende database moet hebben.
Laten we nu aannemen dat de website de volledige controle heeft over de respectievelijke database die de mogelijkheid biedt om records te verwijderen, tabellen toe te voegen / te verwijderen, nieuwe beveiligingsaccounts toe te voegen, enz. Het is belangrijk op te merken dat sommige webtoepassingen dit type toestemming nodig hebben. Het is niet automatisch een slechte zaak dat volledige controle wordt verleend.
Dus om de schade te illustreren die in deze situatie kan worden aangericht, zullen we het voorbeeld uit de bovenstaande strip gebruiken door het volgende in het veld gebruikersnaam in te voeren:
"Robert '; DROP TABLE-gebruikers; -".
Na eenvoudige vervanging wordt de authenticatievraag:
SELECTEER UserID VAN gebruikers WAAR UserName = 'Robert'; DROP TABLE-gebruikers; - 'AND Password =' wrongpass '
Opmerking: de puntkomma in een SQL-query wordt gebruikt om het einde van een bepaalde instructie en het begin van een nieuwe instructie aan te duiden.
Die wordt uitgevoerd door de database als:
SELECTEER UserID VAN gebruikers WAAR UserName = 'Robert'DROP TABLE-gebruikers
We hebben dus zomaar een SQLI-aanval gebruikt om de hele tabel Gebruikers te verwijderen.
Natuurlijk kan er veel erger worden gedaan, aangezien de aanvaller, afhankelijk van de toegestane SQL-machtigingen, waarden kan wijzigen, tabellen (of de hele database zelf) naar een tekstbestand kan dumpen, nieuwe inlogaccounts kan aanmaken of zelfs de hele database-installatie kan kapen.
Voorkomen van een SQL-injectie-aanval
Zoals we al meerdere keren eerder hebben vermeld, is een SQL-injectie-aanval gemakkelijk te voorkomen. Een van de belangrijkste regels van webontwikkeling is dat u nooit blindelings de invoer van gebruikers vertrouwt, zoals we deden toen we een eenvoudige vervanging uitvoerden in onze sjabloonquery hierboven.
Een SQLI-aanval wordt gemakkelijk gedwarsboomd door het zogenaamde opschonen (of ontsnappen) van uw invoer. Het opschoningsproces is eigenlijk vrij triviaal, aangezien het in wezen alleen inline enkele aanhalingstekens (‘) op de juiste manier afhandelt, zodat ze niet kunnen worden gebruikt om een tekenreeks binnen een SQL-instructie voortijdig te beëindigen.
Als u bijvoorbeeld "O’neil" in een database wilt opzoeken, kunt u geen eenvoudige vervanging gebruiken, omdat het enkele aanhalingsteken na de O ervoor zorgt dat de tekenreeks voortijdig eindigt. In plaats daarvan reinigt u het door het escape-teken van de respectieve database te gebruiken. Laten we aannemen dat het escape-teken voor een inline enkel aanhalingsteken elk citaat voorafgaat aan een \ -symbool. Dus "O’neal" zou worden gezuiverd als "O \’ neil ".
Deze simpele sanitaire handeling voorkomt vrijwel een SQLI-aanval. Laten we ter illustratie onze vorige voorbeelden opnieuw bekijken en de resulterende zoekopdrachten bekijken wanneer de gebruikersinvoer is opgeschoond.
myuser '-
/
verkeerde pas
:
SELECTEER Gebruikers-ID VAN Gebruikers WAAR UserName = 'myuser \' - 'AND Password =' wrongpass '
Omdat het enkele aanhalingsteken na myuser is ontsnapt (wat betekent dat het wordt beschouwd als onderdeel van de doelwaarde), zal de database letterlijk zoeken naar de gebruikersnaam van
"myuser '-".
Bovendien, omdat de streepjes zijn opgenomen in de tekenreekswaarde en niet in de SQL-instructie zelf, worden ze beschouwd als onderdeel van de doelwaarde in plaats van te worden geïnterpreteerd als een SQL-opmerking.
Robert '; DROP TABLE-gebruikers; -
/
verkeerde pas
:
SELECTEER UserID VAN gebruikers WAAR UserName = 'Robert \'; DROP TABLE-gebruikers; - 'AND Password =' wrongpass '
Door simpelweg aan het enkele aanhalingsteken na Robert te ontsnappen, bevinden zowel de puntkomma als de streepjes zich in de zoekreeks UserName, zodat de database letterlijk zal zoeken naar
"Robert '; DROP TABLE-gebruikers; -"
in plaats van het verwijderen van de tabel uit te voeren.
Samengevat
Terwijl webaanvallen evolueren en geavanceerder worden of zich richten op een ander punt van binnenkomst, is het belangrijk om te onthouden dat u bescherming moet bieden tegen beproefde aanvallen die de inspiratie zijn geweest voor verschillende gratis beschikbare "hackertools" die zijn ontworpen om ze te exploiteren.
Bepaalde soorten aanvallen, zoals DDoS, kunnen niet gemakkelijk worden vermeden, terwijl andere, zoals SQLI, dat wel kunnen. De schade die door dit soort aanvallen kan worden aangericht, kan variëren van ongemak tot catastrofaal, afhankelijk van de genomen voorzorgsmaatregelen.
