26Aug
Zelfs als je de gebeurtenissen van de hackergroepen Anonymous en LulzSec slechts losjes hebt gevolgd, heb je waarschijnlijk gehoord van websites en services die worden gehackt, zoals de beruchte Sony-hacks. Heb je je ooit afgevraagd hoe ze het doen?
Er zijn een aantal hulpmiddelen 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 je consequent hoort, zijn "(Distributed) Denial of Service"( DDoS) en "SQL Injections"( SQLI).Dit is hoe ze werken.
Afbeelding door xkcd
Denial of Service Attack
Wat is het?
Een "denial of service"( soms een "distributed denial of service" of DDoS) -aanval genoemd doet zich voor wanneer een systeem, in dit geval een webserver, zoveel verzoeken tegelijkertijd ontvangt dat de serverbronnen overbelast zijn, het systeem eenvoudig vergrendeltomhoog en wordt afgesloten. Het doel en het resultaat van een succesvolle DDoS-aanval is dat de websites op de doelserver niet beschikbaar zijn voor legitieme verkeersaanvragen.
Hoe werkt het?
De logistiek van een DDoS-aanval kan het beste worden verklaard aan de hand van een voorbeeld.
Stel je voor dat een miljoen mensen( de aanvallers) samenkomen met als doel het bedrijf van Company X te belemmeren door hun callcenter neer te halen. De aanvallers coördineren zodat ze op dinsdag om 9 uur 's ochtends allemaal het telefoonnummer van bedrijf X bellen. Hoogstwaarschijnlijk zal het telefoonsysteem van het bedrijf X niet in staat zijn om een miljoen telefoontjes tegelijk af te handelen, zodat alle inkomende lijnen door de aanvallers worden vastgezet. Het resultaat is dat legitieme klantenbezoeken( dat wil zeggen die niet de aanvallers zijn) niet doorkomen omdat het telefoonsysteem vastzit aan het verwerken van de oproepen van de aanvallers. Dus in essentie verliest bedrijf X potentieel verlies door het feit dat legitieme verzoeken niet kunnen worden verwerkt.
Een DDoS-aanval op een webserver werkt precies hetzelfde. 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 meestal zeer effectief.
De aanval uitvoeren
Vanwege de "brute force" aard van een DDoS-aanval, moet je veel computers hebben die allemaal gecoördineerd zijn om tegelijkertijd aan te vallen. Als we bijvoorbeeld ons voorbeeld van een callcenter opnieuw bezoeken, zouden alle aanvallers moeten weten dat ze om 9 uur 's morgens moeten bellen en op dat moment daadwerkelijk moeten bellen. Hoewel dit principe zeker werkt als het gaat om aanvallen op een webserver, wordt het aanzienlijk eenvoudiger 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, sluimeren en af en toe 'opbellen' voor instructies. Een van deze instructies kan bijvoorbeeld zijn om herhaalde verzoeken naar de webserver van Company X te sturen om 9 uur 's ochtends. Dus met een enkele update van de thuislocatie van de betreffende malware, kan een enkele aanvaller onmiddellijk honderdduizenden besmette 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 omdat de aanvaller zijn computer helemaal niet hoeft te gebruiken om de aanval uit te voeren.
SQL Injection Attack
Wat is het?
Een "SQL-injectie"( SQLI) -aanval is een exploit die gebruik maakt van slechte webontwikkeltechnieken en, meestal gecombineerd met, gebrekkige databasebeveiliging. Het resultaat van een succesvolle aanval kan variëren van zich voordoen als een gebruikersaccount tot een volledig compromis van de betreffende database of server. In tegenstelling tot een DDoS-aanval, is een SQLI-aanval volledig en gemakkelijk te voorkomen als een webtoepassing op de juiste manier is geprogrammeerd.
De aanval uitvoeren
Telkens wanneer u zich aanmeldt bij een website en uw gebruikersnaam en wachtwoord invoert, kan de webtoepassing een zoekopdracht uitvoeren zoals de volgende om uw referenties te testen:
SELECT UserID FROM Users WHERE UserName = 'myuser' AND Password= "mypass;
Opmerking: stringwaarden in een SQL-query moeten tussen enkele aanhalingstekens staan en daarom verschijnen ze rond de door de gebruiker ingevoerde waarden.
Dus moet de combinatie van de ingevoerde gebruikersnaam( myuser) en wachtwoord( mypass) overeenkomen met een invoer in de tabel Gebruikers om een gebruikers-ID te retourneren. Als er geen overeenkomst is, wordt geen gebruikers-ID geretourneerd, zodat de inloggegevens ongeldig zijn. Hoewel een bepaalde implementatie kan verschillen, zijn de mechanica behoorlijk standaard.
Laten we nu dus kijken naar een sjabloonverificatievraag die we kunnen vervangen door de waarden die de gebruiker invoert op het webformulier:
SELECT gebruikers-ID VAN gebruikers WHERE UserName = '[gebruiker]' EN wachtwoord = '[pass]'
Op het eerste gezicht ditlijkt misschien een eenvoudige en logische stap voor het eenvoudig valideren van gebruikers, maar als een eenvoudige vervanging van de door de gebruiker ingevoerde waarden wordt uitgevoerd op deze sjabloon, is deze vatbaar voor een SQLI-aanval.
Stel bijvoorbeeld dat "myuser'-" is ingevoerd in het veld gebruikersnaam en "wrongpass" is ingevoerd in het wachtwoord. Met behulp van eenvoudige vervanging in onze sjabloonquery, zouden we dit krijgen:
SELECT gebruikers-ID VAN gebruikers WHERE UserName = 'myuser' - 'AND Password =' wrongpass '
Een sleutel voor deze verklaring is het opnemen van de twee streepjes( -).Dit is het begintoken-commentaar voor SQL-instructies, dus alles dat na de twee streepjes( inclusief) wordt weergegeven, wordt genegeerd. In wezen wordt de bovenstaande query door de database uitgevoerd als:
SELECT UserID FROM Users WHERE UserName = 'myuser'
De flagrante omissie hier is het ontbreken van de wachtwoordcontrole. Door de twee streepjes op te nemen als onderdeel van het gebruikersveld, omzeilden we de wachtwoordcontrole-conditie volledig en konden we inloggen als "myuser" zonder het respectieve wachtwoord te kennen. Deze handeling van het manipuleren van de query om onbedoelde resultaten te produceren, is een SQL-injectieaanval.
Welke schade kan worden aangericht?
Een SQL-injectie-aanval wordt veroorzaakt door nalatige en onverantwoordelijke applicatiecodering en is volledig te voorkomen( wat we in een ogenblik zullen behandelen), maar de omvang van de schade die kan worden veroorzaakt, is afhankelijk van de database-instelling. Om ervoor te zorgen dat een webtoepassing kan communiceren met de back-enddatabase, moet de applicatie inloggen bij de database( merk op dat dit anders is dan het inloggen van een gebruiker op de website zelf).Afhankelijk van de machtigingen die de webtoepassing vereist, kan dit respectieve databaseaccount om het even wat vragen, van lees- / schrijfrechten in bestaande tabellen tot volledige databasetoegang. Als dit nu niet duidelijk is, zouden een paar voorbeelden voor meer duidelijkheid moeten zorgen.
Op basis van het bovenstaande voorbeeld, kunt u zien dat door bijvoorbeeld "uwgebruiker" - "," admin "-" of een andere gebruikersnaam in te voeren, wij ons onmiddellijk als die gebruiker op de site kunnen aanmelden zonder het wachtwoord te kennen. Als we eenmaal in het systeem zijn, weten we niet dat we niet echt die gebruiker zijn, dus hebben we volledige toegang tot het betreffende account. Databasemachtigingen bieden hiervoor geen vangnet, omdat een website doorgaans ten minste lees- / schrijftoegang tot zijn respectieve database moet hebben.
Laten we nu aannemen dat de website volledige controle heeft over zijn respectieve database die de mogelijkheid biedt om records te verwijderen, tabellen toe te voegen / te verwijderen, nieuwe beveiligingsaccounts toe te voegen, enz. Het is belangrijk om te weten dat sommige webtoepassingen dit type toestemming nodig hebben, dushet is niet automatisch een slechte zaak dat volledige controle wordt verleend.
Dus om de schade aan te tonen die in deze situatie kan worden gedaan, zullen we het voorbeeld in de strip hierboven gebruiken door het volgende in te voeren in het veld gebruikersnaam: "Robert"; DROP TABLE Users; - ".Na een eenvoudige vervanging wordt de authenticatiequery:
SELECT UserID FROM Users WHERE UserName = 'Robert';DROP TABLE Users; - 'AND Password =' wrongpass '
Opmerking: de puntkomma in een SQL-query wordt gebruikt om het einde van een bepaalde instructie aan te geven en het begin van een nieuwe instructie.
Welke wordt uitgevoerd door de database als:
SELECT UserID VAN gebruikers WHERE UserName = 'Robert'
DROP TABLE Gebruikers
Dus zo hebben we een SQLI-aanval gebruikt om de hele tabel Gebruikers te verwijderen.
Natuurlijk kan er nog veel erger aan gedaan worden, afhankelijk van de toegestane SQL-permissies, kan de aanvaller waarden veranderen, tabellen( of de hele database zelf) naar een tekstbestand dumpen, nieuwe login-accounts maken of zelfs de hele database-installatie kapen.
Voorkomen van een SQL-injectie-aanval
Zoals we al verschillende keren eerder hebben vermeld, is een SQL-injectie-aanval gemakkelijk te voorkomen. Een van de belangrijkste regels voor webontwikkeling is dat u nooit blindelings de invoer van gebruikers vertrouwt, zoals we deden toen we in onze sjabloonquery hierboven een eenvoudige vervanging uitvoerden.
Een SQLI-aanval wordt gemakkelijk gedwarsboomd door wat je ingangen ontsmet( of ontsnapt).Het zuiveringsproces is eigenlijk vrij triviaal, omdat het in essentie alleen maar alle inline enkele aanhalingstekens( ') goed behandelt, 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 eenvoudige vervanging niet gebruiken omdat het enkele aanhalingsteken na de O ervoor zou zorgen dat de tekenreeks voortijdig eindigt. In plaats daarvan zuiver je het door het escape-teken van de betreffende database te gebruiken. Laten we aannemen dat het escape-teken voor een inline enkel aanhalingsteken elke quote met een \ -symbool voorafgaat. Dus "O'neal" zou worden gezuiverd als "O \ 'neil".
Deze eenvoudige sanitaire handeling voorkomt vrijwel een SQLI-aanval. Ter illustratie laten we onze vorige voorbeelden opnieuw bekijken en de resulterende query's bekijken wanneer de invoer van de gebruiker is opgeschoond.
myuser '- / wrongpass :
SELECT UserID FROM Users WHERE UserName =' myuser '-' AND Password = 'wrongpass'
Omdat het enkele aanhalingsteken nadat myuser is geëscaped( wat betekent dat het wordt beschouwd als onderdeel van het doelwaarde), zal de database letterlijk zoeken naar de gebruikersnaam van "myuser" - ".Omdat de streepjes zijn opgenomen in de tekenreekswaarde en niet de SQL-instructie zelf, worden ze bovendien als onderdeel van de doelwaarde beschouwd in plaats van te worden geïnterpreteerd als een SQL-opmerking.
Robert ';DROP TABLE Users; - / wrongpass :
SELECT UserID FROM Users WHERE UserName = 'Robert \';DROP TABLE-gebruikers; - 'AND Password =' wrongpass '
Door simpelweg aan het enkele citaat na Robert te ontsnappen, bevinden zowel de puntkomma als de streepjes zich binnen de zoekreeks, zodat de database letterlijk naar "Robert" zoekt; DROP TABLE Users;- "in plaats van de tabel te verwijderen.
Samenvattend
Terwijl webaanvallen evolueren en geavanceerder worden of zich richten op een ander punt van binnenkomst, is het belangrijk om te onthouden dat je moet beschermen tegen beproefde aanvallen die de inspiratie waren van verschillende vrij beschikbare "hacker-tools" die zijn ontworpen om ze te exploiteren.
Bepaalde typen aanvallen, zoals DDoS, kunnen niet gemakkelijk worden vermeden, terwijl andere, zoals SQLI, dit wel kunnen. De schade die kan worden toegebracht door dit soort aanvallen kan echter variëren van een ongemak tot catastrofaal, afhankelijk van de genomen voorzorgsmaatregelen.
