Zelfs als u de gebeurtenissen van de hackergroepen Anonymous en LulzSec slechts losjes hebt gevolgd, heeft u waarschijnlijk wel eens gehoord van websites en services die gehackt worden, 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 je geen handleiding proberen 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 van xkcd

Denial of Service Attack

Wat is het?

Een "Denial of Service" (soms een "distributed denial of service" of DDoS genoemd) aanval treedt op wanneer een systeem, in dit geval een webserver, zoveel verzoeken tegelijk ontvangt dat de serverbronnen overbelast raken, het systeem gewoon op slot gaat en afgesloten wordt. 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 doordat de legitieme verzoeken niet kunnen worden verwerkt.

Een DDoS-aanval op een webserver werkt op precies dezelfde manier. Omdat er vrijwel niet bekend is welk verkeer afkomstig is van legitieme verzoeken versus aanvallers totdat de webserver de aanvraag verwerkt, is dit type aanval meestal zeer effectief.

De aanval uitvoeren

Vanwege de "brute" dwingend "de 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 zombie-computers, in plaats van echte bemande computers, worden gebruikt. Zoals u waarschijnlijk weet, zijn er veel varianten van malware en Trojaanse paarden die , eenmaal op uw systeem, sluimerend liggen en af ​​en toe "naar huis bellen" 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 in zijn effectiviteit, maar ook ook in zijn anonimiteit aangezien de aanvaller zijn computer helemaal niet hoeft te gebruiken om de aanval uit te voeren.

Aanval met SQL-injectie

Wat is het?

Een "SQL-injectie" (SQLI) aanval is een exploit die profiteert 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

Wanneer u zich aanmeldt bij een website en uw gebruikersnaam en wachtwoord invoert om uw referenties de webtoepassing kan een query uitvoeren zoals de volgende:

SELECT UserID FROM Users WHERE UserName = "myuser" AND Password = "mypass";

Opmerking: stringwaarden in een SQL-query moeten tussen enkele aanhalingstekens worden geplaatst en daarom verschijnen ze rond de door de gebruiker ingevoerde waarden.

Dus de combinatie van de ingevoerde gebruikersnaam (myuser) en wachtwoord (mypass) moet overeenkomen met een item in de Gebruikers tabel 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 eens naar een sjabloonverificatiequery kijken die we kunnen vervangen door de waarden die de gebruiker invoert op het webformulier:

SELECT UserID FROM Users WHERE UserName = " [user] "AND Password =" [pass] "

Op het eerste gezicht lijkt dit 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 het vatbaar voor een SQLI-aanval.

Stel dat "myuser'-" is ingevoerd in het veld gebruikersnaam en "wrongpass" is ingevoerd in het wachtwoord. Met behulp van eenvoudige substitutie in onze sjabloonquery, zouden we dit krijgen:

SELECT UserID FROM Users WHERE UserName = "myuser" - 'AND Password = "wrongpass"

Een sleutel tot deze verklaring is de opname 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 om de query te manipuleren om onbedoelde resultaten te produceren, is een SQL-injectieaanval.

Welke schade kan worden aangericht?

Een SQL-injectieaanval wordt veroorzaakt door nalatige en onverantwoordelijke codering van de toepassing en is volledig te voorkomen (die we zullen behandelen in een moment), 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 een gebruikersaanmelding bij 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, kunnen enkele voorbeelden enige duidelijkheid bieden.

Op basis van het bovenstaande voorbeeld kunt u dat zien door bijvoorbeeld

"uwuser" - "," admin'- in te voeren - "

of elke andere gebruikersnaam, we kunnen onmiddellijk als die gebruiker inloggen op de site 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 op zijn minst lees- / schrijftoegang moet hebben tot zijn respectieve database. Laten we nu aannemen dat de website de 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, etc. Het is belangrijk op te merken dat sommige webtoepassingen dit type toestemming nodig hebben, dus het is niet automatisch een slechte zaak dat volledige controle wordt verleend.illustreren de schade die in deze situatie kan worden aangericht, we zullen het voorbeeld in de bovenstaande strip gebruiken door het volgende in te voeren in het veld gebruikersnaam:"Robert"; DROP TABLE Users; - ".

After eenvoudige vervanging de verificatiequery wordt:

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 FROM Users WHERE UserName = "Robert"

DROP TABLE Users

Zo hebben we daarom een ​​SQLI-aanval gebruikt om de hele tabel met 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 gehele 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 je nooit blindelings de invoer van gebruikers vertrouwt, zoals we deden toen we in onze bovenstaande sjabloonvraag een eenvoudige vervanging uitvoerden.

Een SQLI-aanval wordt gemakkelijk gedwarsboomd door wat je ingangen ontsmet (of ontsnapt). Het opschoningsproces 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 een query wilt uitvoeren opzoeken "O'neil" in een database, kon je eenvoudige vervanging niet gebruiken omdat het enkele aanhalingsteken na de O ervoor zou zorgen dat de reeks voortijdig zou eindigen. 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 voorafgaat aan elk citaat met een -symbool. Dus "O'neal" zou worden gezuiverd als "O 'neil".

Deze eenvoudige sanitaire handeling voorkomt vrijwel een SQLI-aanval. Laten we illustreren dat 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 een deel van de doelwaarde), de database letterlijk zal zoeken naar de gebruikersnaam van " myuser " - ".

Omdat de streepjes zijn opgenomen in de tekenreekswaarde en niet 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 Users; -/wrongpass

: SELECT UserID FROM Users WHERE UserName = "Robert "; DROP TABLE Users; - 'AND Password = "wrongpass" Door simpelweg te ontsnappen aan het enkele citaat achter Robert, bevinden zowel de puntkomma als de streepjes zich in de zoekreeks van UserName zodat de database letterlijk zal zoeken naar "Robert" ; DROP TABLE Users; - "

in plaats van het uitvoeren van de tabelverwijdering.

SamenvattendTerwijl webaanvallen evolueren en geavanceerder worden of zich richten op een ander punt van binnenkomst, is het belangrijk om te onthouden om te beschermen tegen beproefde aanvallen die de inspiratie waren van verschillende vrij beschikbare "hacker-tools" die ontworpen zijn om ze te exploiteren.Bepaalde typen aanvallen, zoals DDoS, kunnen niet gemakkelijk worden vermeden, terwijl anderen, 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.

Hoe OS X virtuele desktops efficiënter te gebruiken met sneltoetsen op het toetsenbord

We willen graag meerdere virtuele desktops op OS X, vooral als we ze kunnen opvoeren door ze te combineren met een paar eenvoudige sneltoetsen. Dus, in dat geval, zijn hier enkele praktische manieren om de virtuele desktops van OS X te gebruiken, zoals je het meent. Virtuele desktops zijn nauwelijks een nieuw concept.

(how-to)

Wat is versleuteling en hoe werkt het?

Versleuteling heeft een lange geschiedenis die teruggaat tot het moment waarop de oude Grieken en Romeinen geheime berichten verstuurden door letters te vervangen die alleen te decoderen waren met een geheime sleutel. Ga met ons mee voor een korte geschiedenisles en ontdek hoe de codering werkt. In de HTG Explains van vandaag geven we u een korte geschiedenis van codering, hoe het werkt en enkele voorbeelden van verschillende soorten codering zeker dat je ook de vorige editie bekijkt, waar we uitlegden waarom zoveel geeks een hekel hebben aan Internet Explorer.

(how-to)