9 populaire aanvalstypen met webapplicatie-injectie

Het probleem met webapplicaties is dat ze openlijk worden blootgesteld aan miljarden internetgebruikers, van wie velen om welke reden dan ook de beveiligingsmaatregelen willen doorbreken.

In de begindagen van het internet was een van de meest voorkomende aanvalsmethoden eenvoudige, eenvoudige brute kracht. Bots voerden deze aanvallen meestal uit – of personen met veel vrije tijd – die ontelbare combinaties van gebruikersnamen en wachtwoorden probeerden totdat ze er een vonden die toegang zou verlenen tot de doeltoepassing.

Brute force-aanvallen vormen geen bedreiging meer dankzij wachtwoordbeleid, beperkte inlogpogingen en captcha’s. Maar cybercriminelen vinden het heerlijk om nieuwe exploits te ontdekken en deze te gebruiken om nieuwe soorten aanvallen uit te voeren. Lang geleden ontdekten ze dat tekstvelden op applicaties of webpagina’s konden worden misbruikt door er onverwachte tekst in te typen of te injecteren die de applicatie zou dwingen iets te doen wat niet de bedoeling was. Zo kwamen de zogenaamde injectie-aanvallen op het toneel.

Injectieaanvallen kunnen niet alleen worden gebruikt om in te loggen op een applicatie zonder de gebruikersnaam en het wachtwoord te kennen, maar ook om privé-, vertrouwelijke of gevoelige informatie bloot te leggen, of zelfs om een ​​hele server te kapen. Daarom vormen deze aanvallen niet alleen een bedreiging voor webapplicaties, maar ook voor de gebruikers van wie de gegevens zich op die applicaties bevinden, en in het ergste geval voor andere aangesloten applicaties en diensten.

Code-injectie

Code-injectie is een van de meest voorkomende soorten injectie-aanvallen. Als aanvallers de programmeertaal, het framework, de database of het besturingssysteem van een webapplicatie kennen, kunnen ze via tekstinvoervelden code injecteren om de webserver te dwingen te doen wat ze willen.

Dit soort injectie-aanvallen is mogelijk op applicaties die geen validatie van invoergegevens hebben. Als een tekstinvoerveld gebruikers laat invoeren wat ze maar willen, dan is de applicatie mogelijk misbruikbaar. Om deze aanvallen te voorkomen, moet de applicatie zoveel mogelijk beperkingen opleggen aan de invoer die gebruikers mogen invoeren.

Het moet bijvoorbeeld de hoeveelheid verwachte gegevens beperken, het gegevensformaat controleren voordat het wordt geaccepteerd en het aantal toegestane tekens beperken.

De kwetsbaarheden voor code-injectie kunnen eenvoudig worden gevonden door de tekstinvoer van een webtoepassing met verschillende soorten inhoud te testen. Wanneer ze worden gevonden, zijn de kwetsbaarheden redelijk moeilijk te misbruiken. Maar wanneer een aanvaller erin slaagt een van deze kwetsbaarheden te misbruiken, kan de impact het verlies van vertrouwelijkheid, integriteit, beschikbaarheid of applicatiefunctionaliteit omvatten.

SQL injectie

Op dezelfde manier als code-injectie, voegt deze aanval een SQL-script – de taal die door de meeste databases wordt gebruikt om querybewerkingen uit te voeren – in een tekstinvoerveld in. Het script wordt naar de applicatie gestuurd, die het rechtstreeks in zijn database uitvoert. Als gevolg hiervan kan de aanvaller een inlogscherm passeren of gevaarlijkere dingen doen, zoals gevoelige gegevens rechtstreeks uit de database lezen, databasegegevens wijzigen of vernietigen of beheerbewerkingen op de database uitvoeren.

  Hoe u Google+ van uw Google-account kunt verwijderen

PHP- en ASP-applicaties zijn gevoelig voor SQL-injectie-aanvallen vanwege de oudere functionele interfaces. J2EE- en ASP.Net-apps zijn meestal beter beschermd tegen deze aanvallen. Wanneer een kwetsbaarheid voor SQL-injectie wordt gevonden – en deze zou gemakkelijk kunnen worden gevonden – wordt de omvang van de potentiële aanvallen alleen beperkt door de vaardigheden en verbeeldingskracht van de aanvaller. De impact van een SQL-injectieaanval is dus ongetwijfeld groot.

Commando injectie

Deze aanvallen zijn ook mogelijk, voornamelijk door onvoldoende invoervalidatie. Ze verschillen van aanvallen met code-injectie doordat de aanvaller systeemopdrachten invoegt in plaats van stukjes programmeercode of scripts. Daarom hoeft de hacker de programmeertaal waarin de applicatie is gebaseerd of de taal die door de database wordt gebruikt, niet te kennen. Maar ze moeten het besturingssysteem kennen dat door de hostingserver wordt gebruikt.

De ingevoegde systeemcommando’s worden uitgevoerd door het hostbesturingssysteem met de rechten van de toepassing, waardoor onder andere de inhoud van willekeurige bestanden op de server kan worden weergegeven, de directorystructuur van een server kan worden weergegeven, gebruikerswachtwoorden kunnen worden gewijzigd .

Deze aanvallen kunnen worden voorkomen door een systeembeheerder door het systeemtoegangsniveau van de webapplicaties die op een server draaien te beperken.

Cross-site scripting

Wanneer een applicatie input van een gebruiker invoegt in de output die het genereert, zonder deze te valideren of te coderen, geeft het een aanvaller de kans om kwaadaardige code naar een andere eindgebruiker te sturen. Cross-Site Scripting (XSS)-aanvallen maken van deze gelegenheid gebruik om kwaadaardige scripts in vertrouwde websites te injecteren, die uiteindelijk worden verzonden naar andere gebruikers van de applicatie, die het slachtoffer worden van de aanvaller.

De browser van de slachtoffers zal het kwaadaardige script uitvoeren zonder te weten dat het niet vertrouwd mag worden. Daarom geeft de browser toegang tot sessietokens, cookies of gevoelige informatie die door de browser is opgeslagen. Indien correct geprogrammeerd, kunnen de scripts zelfs de inhoud van een HTML-bestand herschrijven.

XSS-aanvallen kunnen over het algemeen worden onderverdeeld in twee verschillende categorieën: opgeslagen en gereflecteerd.

Bij opgeslagen XSS-aanvallen bevindt het kwaadaardige script zich permanent op de doelserver, in een berichtenforum, in een database, in een bezoekerslogboek, enz. Het slachtoffer krijgt het wanneer zijn browser de opgeslagen informatie opvraagt. Bij gereflecteerde XSS-aanvallen wordt het schadelijke script weerspiegeld in een reactie die de invoer naar de server bevat. Dit kan bijvoorbeeld een foutmelding zijn of een zoekresultaat.

XPath-injectie

Dit type aanval is mogelijk wanneer een webtoepassing informatie van een gebruiker gebruikt om een ​​XPath-query voor XML-gegevens te bouwen. De manier waarop deze aanval werkt, is vergelijkbaar met SQL-injectie: aanvallers sturen misvormde informatie naar de applicatie om erachter te komen hoe de XML-gegevens zijn gestructureerd, en vallen vervolgens opnieuw aan om toegang te krijgen tot die gegevens.

  Hoe de vertrouwelijke modus in Gmail te gebruiken

XPath is een standaardtaal waarmee je, net als SQL, de attributen kunt specificeren die je wilt vinden. Om een ​​query op XML-gegevens uit te voeren, gebruiken webtoepassingen gebruikersinvoer om een ​​patroon in te stellen waarmee de gegevens moeten overeenkomen. Door onjuiste invoer te verzenden, kan het patroon veranderen in een bewerking die de aanvaller op de gegevens wil toepassen.

In tegenstelling tot wat er met SQL gebeurt, zijn er in XPath geen verschillende versies. Dit betekent dat XPath-injectie kan worden uitgevoerd op elke webtoepassing die XML-gegevens gebruikt, ongeacht de implementatie. Dat betekent ook dat de aanval geautomatiseerd kan worden; daarom kan het, in tegenstelling tot SQL-injectie, worden afgevuurd op een willekeurig aantal doelen.

Mail commando-injectie

Deze aanvalsmethode kan worden gebruikt om e-mailservers en toepassingen te misbruiken die IMAP- of SMTP-verklaringen bouwen met onjuist gevalideerde gebruikersinvoer. Af en toe hebben IMAP- en SMTP-servers geen sterke bescherming tegen aanvallen, zoals bij de meeste webservers het geval is, en kunnen ze daarom beter worden misbruikt. Door via een mailserver binnen te komen, konden aanvallers beperkingen zoals captcha’s, een beperkt aantal verzoeken, enz.

Om een ​​SMTP-server te misbruiken, hebben aanvallers een geldig e-mailaccount nodig om berichten met geïnjecteerde opdrachten te verzenden. Als de server kwetsbaar is, reageert deze op verzoeken van aanvallers, waardoor ze bijvoorbeeld serverbeperkingen kunnen opheffen en zijn services kunnen gebruiken om spam te verzenden.

IMAP-injectie kan voornamelijk worden gedaan op webmailtoepassingen, gebruikmakend van de functie voor het lezen van berichten. In deze gevallen kan de aanval worden uitgevoerd door simpelweg in de adresbalk van een webbrowser een URL in te voeren met de geïnjecteerde opdrachten.

CRLF-injectie

Het invoegen van regelterugloop- en regelinvoertekens – een combinatie die bekend staat als CRLF – in invoervelden van webformulieren vertegenwoordigt een aanvalsmethode die CRLF-injectie wordt genoemd. Deze onzichtbare tekens geven het einde van een regel of het einde van een opdracht aan in veel traditionele internetprotocollen, zoals HTTP, MIME of NNTP.

De invoeging van een CRLF in een HTTP-verzoek, gevolgd door een bepaalde HTML-code, kan bijvoorbeeld aangepaste webpagina’s naar de bezoekers van een website sturen.

Deze aanval kan worden uitgevoerd op kwetsbare webapplicaties die niet de juiste filtering toepassen op de gebruikersinvoer. Deze kwetsbaarheid opent de deur naar andere soorten injectie-aanvallen, zoals XSS en code-injectie, en kan ook leiden tot het kapen van een website.

Host Header-injectie

Op servers die veel websites of webapplicaties hosten, wordt de hostheader noodzakelijk om te bepalen welke van de residente websites of webapplicaties – elk bekend als een virtuele host – een inkomend verzoek moet verwerken. De waarde van de header vertelt de server naar welke van de virtuele hosts een verzoek moet worden verzonden. Wanneer de server een ongeldige hostheader ontvangt, wordt deze meestal doorgegeven aan de eerste virtuele host in de lijst. Dit vormt een kwetsbaarheid die aanvallers kunnen gebruiken om willekeurige hostheaders naar de eerste virtuele host in een server te sturen.

  7 Beste PDF-editors op Mac om de productiviteit te verbeteren

Manipulatie van de hostheader is meestal gerelateerd aan PHP-applicaties, hoewel het ook kan worden gedaan met andere webontwikkelingstechnologieën. Host-headeraanvallen werken als enablers voor andere soorten aanvallen, zoals webcache-vergiftiging. De gevolgen kunnen de uitvoering van gevoelige bewerkingen door de aanvallers zijn, bijvoorbeeld het resetten van wachtwoorden.

LDAP-injectie

LDAP is een protocol dat is ontworpen om het zoeken naar bronnen (apparaten, bestanden, andere gebruikers) in een netwerk te vergemakkelijken. Het is erg handig voor intranetten en wanneer het wordt gebruikt als onderdeel van een systeem voor eenmalige aanmelding, kan het worden gebruikt om gebruikersnamen en wachtwoorden op te slaan. Bij LDAP-query’s worden speciale besturingstekens gebruikt die van invloed zijn op de besturing. Aanvallers kunnen mogelijk het bedoelde gedrag van een LDAP-query wijzigen als ze er besturingstekens in kunnen invoegen.

Nogmaals, het kernprobleem dat LDAP-injectieaanvallen mogelijk maakt, is onjuist gevalideerde gebruikersinvoer. Als de tekst die een gebruiker naar een applicatie stuurt, wordt gebruikt als onderdeel van een LDAP-query zonder deze op te schonen, kan de query ertoe leiden dat een lijst met alle gebruikers wordt opgehaald en aan een aanvaller wordt getoond, gewoon door een asterisk te gebruiken

op de juiste plaats in een invoerreeks.

Injectie-aanvallen voorkomen

Zoals we in dit artikel hebben gezien, zijn alle injectie-aanvallen gericht op servers en applicaties met open toegang voor elke internetgebruiker. De verantwoordelijkheid om deze aanvallen te voorkomen wordt verdeeld onder applicatieontwikkelaars en serverbeheerders.

Applicatieontwikkelaars moeten de risico’s kennen die gepaard gaan met de onjuiste validatie van gebruikersinvoer en best practices leren om gebruikersinvoer op te schonen met het oog op risicopreventie. Serverbeheerders moeten hun systemen periodiek controleren om kwetsbaarheden op te sporen en deze zo snel mogelijk te corrigeren. Er zijn veel opties om deze audits uit te voeren, zowel on-demand als automatisch.

gerelateerde berichten