Wat zijn CSRF-aanvallen en hoe kunt u ze voorkomen?

Cross-Site Request Forgery (CSRF) is een van de oudste manieren om de kwetsbaarheden van een website te misbruiken. Het is gericht op webswitches aan de serverzijde die meestal authenticatie vereisen, zoals inloggen. Tijdens een CSRF-aanval probeert een aanvaller zijn slachtoffer te dwingen namens hen een ongeautoriseerd, kwaadaardig webverzoek te doen.

Zwakke of slechte praktijken op het gebied van websitebeveiliging en onvoorzichtigheid op het pad van de gebruiker zijn enkele van de meest voorkomende oorzaken van een succesvolle CSRF-aanval.

Laten we eens kijken naar wat een CSRF-aanval is en de mogelijke manieren waarop u uzelf als ontwikkelaar of als gebruiker kunt voorkomen.

Hoe beïnvloeden CSRF-aanvallen u?

Een CSRF is een aanval die wordt gebruikt om ongeautoriseerde verzoeken uit te voeren tijdens webacties waarvoor gebruikersaanmelding of authenticatie is vereist. CSRF-aanvallen kunnen profiteren van sessie-ID's, cookies en andere servergebaseerde kwetsbaarheden om de inloggegevens van een gebruiker te stelen.

Door bijvoorbeeld anti-CSRF-procedures in te schakelen, worden kwaadaardige interacties tussen domeinen voorkomen.

Zodra die barrière doorbreekt, kan een aanvaller snel profiteren van de sessie-ID van de gebruiker via de cookies die door de browser van de gebruiker zijn gemaakt en een scripttag in de kwetsbare website insluiten.

Door een ID te manipuleren, kan de aanvaller bezoekers ook omleiden naar een andere webpagina of gebruikmaken van social engineering-methoden zoals e-mail om links te verzenden, waardoor het slachtoffer wordt aangemoedigd om schadelijke software te downloaden.

Zodra het slachtoffer dergelijke acties uitvoert, stuurt het een HTTP-verzoek naar de servicepagina van de gebruiker en autoriseert het de verzoekactie in het voordeel van de aanvaller. Dat kan verwoestend zijn voor een nietsvermoedende gebruiker.

Een succesvolle CSRF-aanval kan ertoe leiden dat geautoriseerde gebruikers hun toegangsgegevens kwijtraken aan een aanvaller, vooral tijdens servergebaseerde acties zoals verzoeken om wachtwoord of gebruikersnaam te wijzigen. In slechtere scenario's neemt de aanvaller de hele sessie over en treedt op namens de gebruikers.

CSRF is gebruikt om over-the-web fondstransacties te kapen en om gebruikersnamen en wachtwoorden te wijzigen, waardoor gebruikers de toegang tot de betreffende service verliezen.

Hoe aanvallers uw sessies kapen met CSRF: voorbeelden

De belangrijkste doelen voor CSRF-aanvallen zijn webacties waarbij de authenticatie van een gebruiker betrokken is. Om succesvol te zijn, heeft het onbedoelde acties van het slachtoffer nodig.

Tijdens een CSRF-aanval zijn GET-, DELETE- en PUT-acties, evenals kwetsbare POST-verzoeken, de belangrijkste doelen van een aanvaller.

Laten we eens kijken naar de betekenis van die termen:

• GET: een verzoek om een ​​resultaat uit de database te verzamelen; bijvoorbeeld Google zoeken.
• POST: Meestal voor het indienen van verzoeken via webformulieren. Een POST-verzoek is gebruikelijk tijdens de registratie of aanmelding van een gebruiker, ook wel authenticatie genoemd.
• VERWIJDEREN: om een ​​bron uit de database te verwijderen. U doet dit telkens wanneer u uw account van een bepaalde webservice verwijdert.
• PUT: Een PUT-verzoek wijzigt of actualiseert een bestaande bron. Een voorbeeld is het wijzigen van je Facebook-naam .

In de praktijk gebruiken aanvallers sessiekaping als back-up van een CSRF-aanval. Bij gebruik van deze combinatie kan de aanvaller een kaping gebruiken om het IP-adres van het slachtoffer te wijzigen.

De wijziging in het IP-adres logt het slachtoffer vervolgens in op een nieuwe website waar de aanvaller een bedrieglijke link heeft geplaatst die een gerepliceerd formulier of gewijzigd serververzoek indient dat ze via CSRF hebben gemaakt.

Een nietsvermoedende gebruiker denkt dan dat de omleiding afkomstig is van de serviceprovider en klikt op de link op de webpagina van de aanvaller. Zodra ze dit hebben gedaan, dienen hackers zonder hun medeweten een formulier in bij het laden van de pagina.

Voorbeeld van een GET Request CSRF-aanval

Stelt u zich eens voor dat u probeert een online betaling uit te voeren via een onbeveiligd e-commerceplatform. De platformeigenaren gebruiken het GET-verzoek om uw transactie te verwerken. Die GET-query kan er als volgt uitzien:

https://websiteurl/pay?amount=$10&company=[company ABC's account]

Een kaper kan uw transactie gemakkelijk stelen door de parameters van het GET-verzoek te wijzigen. Om dit te doen, hoeven ze alleen maar uw naam te ruilen voor die van hen, en erger nog, het bedrag dat u van plan bent te betalen te wijzigen. Vervolgens tweaken ze de oorspronkelijke query naar iets als dit:

https://websiteurl/pay?amount=$20000&company=[attacker's account]

Zodra u op een link naar dat gewijzigde GET-verzoek klikt, maakt u uiteindelijk een onbedoelde overdracht naar het account van de aanvaller.

Transacties uitvoeren via GET-verzoeken is een slechte gewoonte en maakt activiteiten kwetsbaar voor aanvallen.

Voorbeeld van een POST-verzoek CSRF-aanval

Veel ontwikkelaars zijn echter van mening dat het gebruik van POST-verzoeken veiliger is voor het uitvoeren van webtransacties. Hoewel dat waar is, is een POST-verzoek helaas ook vatbaar voor CSRF-aanvallen.

Om een ​​POST-verzoek met succes te kapen, heeft een aanvaller alleen uw huidige sessie-ID, enkele gerepliceerde onzichtbare formulieren en soms een beetje social engineering nodig.

Een POST-aanvraagformulier kan er bijvoorbeeld als volgt uitzien:

Een aanvaller kan uw inloggegevens echter omwisselen door een nieuwe pagina te maken en het bovenstaande formulier hierin aan te passen:

In het gemanipuleerde formulier stelt de aanvaller de waarde van het bedragveld in op "30000", wisselt het rekeningnummer van de ontvanger naar dat van hen, verzendt het formulier bij het laden van de pagina en verbergt ook de formuliervelden voor de gebruiker.

Zodra ze die huidige sessie hebben gekaapt, initieert uw transactiepagina een omleiding naar de pagina van de aanvaller, die u vraagt ​​op een link te klikken waarvan zij weten dat u deze waarschijnlijk zult bezoeken.

Als u hierop klikt, wordt de indiening van het gerepliceerde formulier geladen, waarmee uw geld wordt overgemaakt naar de account van de aanvaller. Dat betekent dat u niet op knoppen zoals "verzenden" hoeft te klikken om de transactie te laten plaatsvinden, aangezien JavaScript dit automatisch doet bij het laden van de volgende webpagina.

Als alternatief kan een aanvaller ook een in HTML ingesloten e-mail opstellen waarin u wordt gevraagd op een koppeling te klikken om hetzelfde formulier voor het laden van de pagina uit te voeren.

Een andere actie die kwetsbaar is voor een CSRF-aanval is een gebruikersnaam- of wachtwoordwijziging, een voorbeeld van een PUT-verzoek. Een aanvaller repliceert uw aanvraagformulier en vervangt uw e-mailadres door dat van hen.

Vervolgens stelen ze uw sessie en leiden u naar een pagina of sturen u een e-mail waarin u wordt gevraagd op een aantrekkelijke link te klikken.

Dat verzendt vervolgens een gemanipuleerd formulier dat de link voor het opnieuw instellen van het wachtwoord naar het e-mailadres van de hacker stuurt in plaats van dat van jou. Op die manier wijzigt de hacker uw wachtwoord en logt hij u uit van uw account.

Hoe CSRF-aanvallen als ontwikkelaar te voorkomen

Een van de beste methoden om een ​​CSRF te voorkomen, is het gebruik van tokens die regelmatig veranderen in plaats van afhankelijk te zijn van sessiecookies voor het uitvoeren van een statuswijziging op de server.

Gerelateerd: Gratis handleidingen om digitale beveiliging te begrijpen en uw privacy te beschermen

Veel moderne backend-frameworks bieden beveiliging tegen CSRF. Dus als u de technische details van het versterken van CSRF zelf wilt vermijden, kunt u dit eenvoudig aanpakken door server-side frameworks te gebruiken die worden geleverd met ingebouwde anti-CSRF-tokens.

Wanneer u een anti-CSRF-token gebruikt, genereren servergebaseerde verzoeken willekeurige tekenreeksen in plaats van de meer statische kwetsbare sessiecookies. Op die manier kunt u uw sessie beschermen tegen geraden worden door de kaper.

Het implementeren van een two-factor authenticatie (2FA)-systeem voor het uitvoeren van transacties op uw web-app verkleint ook de kans op een CSRF.

Het is mogelijk om een ​​CSRF te starten via cross-site scripting (XSS), waarbij scripts worden geïnjecteerd in gebruikersvelden zoals commentaarformulieren. Om dit te voorkomen, is het een goede gewoonte om HTML auto-escape in te schakelen in alle velden van het gebruikersformulier op uw website. Die actie voorkomt dat formuliervelden HTML-elementen interpreteren.

Hoe CSRF-aanvallen als gebruiker te voorkomen?

Als gebruiker van een webservice die authenticatie omvat, moet u een rol spelen om te voorkomen dat aanvallers uw inloggegevens en sessies ook via CSRF stelen.

Zorg ervoor dat u vertrouwde webservices gebruikt tijdens activiteiten waarbij geld wordt overgemaakt.

Gebruik daarnaast  veilige webbrowsers die gebruikers beschermen tegen blootstelling aan sessies, evenals beveiligde zoekmachines die beschermen tegen lekken van zoekgegevens.

Gerelateerd:  Beste privézoekmachines die uw gegevens respecteren

Als gebruiker kunt u ook vertrouwen op authenticatiemiddelen van derden, zoals Google Authenticator of zijn alternatieven voor het verifiëren van uw identiteit via internet.

Hoewel u zich misschien hulpeloos voelt om te voorkomen dat een aanvaller uw sessie kapt, kunt u dit toch helpen voorkomen door ervoor te zorgen dat uw browser geen informatie opslaat zoals wachtwoorden en andere inloggegevens.

Verbeter uw webbeveiliging

Ontwikkelaars moeten web-apps regelmatig testen op beveiligingsinbreuken tijdens ontwikkeling en implementatie.

Het is echter gebruikelijk om andere kwetsbaarheden te introduceren terwijl u andere probeert te voorkomen. Zorg er dus voor dat u geen andere beveiligingsparameters hebt geschonden terwijl u een CSRF probeert te blokkeren.