Welkom terug bij onze blogserie waarin we de meest opvallende en relevante kwetsbaarheden onder de loep nemen. Binnen de blogserie hebben we de  XXS kwetsbaarheid behandeld, IDOR, SQL en vandaag gaan we verder met Cross Site Request Forgery (CSRF) kwetsbaarheid. 

Vraag je je af wat er zo tricky is aan deze kwetsbaarheid en waar je je bewust van moet zijn? Lees verder om het antwoord op deze vraag te vinden, evenals meer inzichten over de verschillende technieken die de aanvaller gebruikt om het doelwit te misleiden, de impact van de aanval, mogelijke ernstniveaus, en, natuurlijk, de manier om het te voorkomen!

Wat is cross-site request forgery?

CSRF of cross-site request forgery is een kwetsbaarheid waarbij een slachtoffer wordt misleid om een wijziging aan te brengen die ze niet van plan waren. Een aanvaller creëert een verzoek dat een Privileged actie zal uitvoeren, zoals het wijzigen van het wachtwoord van de huidige gebruiker. Het slachtoffer wordt verleid om het verzoek van de aanvaller uit te voeren binnen zijn eigen beveiligingscontext. In dit geval verandert het slachtoffer niet zijn eigen wachtwoord, maar wordt het wachtwoord van het slachtoffer veranderd. De reden dat dit werkt, is dat de beveiligingscontext soms wordt bepaald door een attribuut (bijv. een beveiligingstoken opgeslagen in een HTTP-cookie) dat automatisch aan het verzoek van het slachtoffer wordt toegevoegd.

Dit verzoek zal een wijziging aanbrengen die alleen door een geautoriseerde gebruiker kan worden gemaakt en zal de aanvaller ten goede komen. Bijvoorbeeld, de aanvaller zal proberen iemand zijn of haar e-mail of wachtwoord te laten veranderen om vervolgens hun account over te nemen, of een verzoek aanmaken dat een slachtoffer geld naar hun rekening laat overmaken. 

Er zijn enkele voorwaarden die moeten worden vervuld voor een CSRF-aanval om te slagen:

• Er is een actie die alleen geautoriseerde gebruikers kunnen uitvoeren en die ook de aanvaller ten goede komt.

• Het gemaakte verzoek wordt gevalideerd met behulp van cookies. 

• Alle vereiste parameters zijn voorspelbaar.

• De actie moet kunnen worden geactiveerd met een link.

CSRF-aanvallen zijn vergelijkbaar met gereflecteerde XSS in de wijze waarop ze worden afgeleverd. Voor beide moet een slachtoffer worden misleid om op een kwaadaardige link te klikken. Bij gereflecteerde XSS is het mogelijk om gegevens van een slachtoffer te ontvangen, met een CSRF-aanval is dit niet mogelijk.
Bij CSRF zijn er verschillende technieken voor POST- en GET-verzoeken.  

POST

Om een link voor een POST-verzoek te maken, kan de aanvaller HTML-code creëren die zijn gekozen staat verandert. Met bijbehorende JavaScript kan het kwaadaardige verzoek automatisch worden ingediend. Deze code wordt vervolgens gehost op een website die door de aanvaller wordt gecontroleerd en de link wordt naar een slachtoffer gestuurd. Na het klikken op de link zal de browser de cookies van de slachtoffers in het verzoek opnemen en de website zal het verzoek normaal afhandelen.

‍GET

Wanneer CSRF mogelijk is in een GET-verzoek, is het niet nodig om HTML-code te creëren. De payload kan rechtstreeks aan de URL worden toegevoegd die dan naar een slachtoffer kan worden gestuurd.

Bijvoorbeeld: www.greatbank.com/transfer?to=attacker&amount=1000 zou duizend euro naar de bankrekening van de aanvaller overmaken. Om deze aanvallen minder verdacht te maken, kunnen de URL's worden vermomd als een ingesloten link. Of door de URL in een afbeelding in te voegen.

Bijvoorbeeld <img src="www.greatbank.com/transfer?to=attacker&amount=1000">. Elk medium dat deze afbeelding probeert te laden, zal het verzoek uitvoeren zonder de kennis van het slachtoffer, zoals hieronder in de afbeelding is te zien.

Impact

De impact van een succesvolle CSRF-aanval is een ongeautoriseerde wijziging namens het slachtoffer. Deze wijziging zal de aanvaller ten goede komen, bijvoorbeeld: 

• Indienen of verwijderen van gegevens.

• Indienen van een transactie.

• Aankoop van een product.

• Wijzigen van persoonlijke profielgegevens.

• Versturen van een bericht.

Wanneer de gebruiker hoge privileges heeft, kan een CSRF-aanval een volledige applicatie compromitteren. 

Ernst 

De ernst van een CSRF-aanval hangt af van de impact van het verzoek. Een CSRF-aanval die een gebruiker laat uitloggen, heeft een informatieve ernst, aangezien er geen impact is, behalve dat het ongemakkelijk is. Een CSRF-aanval met kritieke of hoge ernst zou een aanval zijn die succesvol is op een gebruiker met hoge privileges. Deze kunnen andere gebruikers hoge privileges geven, die dan een volledig systeem kunnen compromitteren.

CSRF-aanvallen kunnen veel ernstige gevolgen hebben, maar vanwege de verschillende voorwaarden die moeten worden vervuld voor een CSRF-aanval om te slagen, kan de ernst lager zijn dan die van andere kwetsbaarheden met een vergelijkbare impact. 

Preventie

CSRF-tokens

Een CSRF-token is een waarde die aan een gebruiker door de server-side applicatie wordt gegeven. Wanneer verzoeken door een gebruiker worden gedaan, wordt het token gevalideerd door de server. CSRF-tokens maken CSRF-aanvallen onmogelijk, omdat een aanvaller de waarde van een token niet kan voorspellen. Zonder het CSRF-token of met een ongeldig token wordt het verzoek door de server afgewezen.

Om CSRF-tokens effectief te maken, moet het aan het volgende voldoen:

• Het CSRF-token moet uniek zijn per sessie.

• Het CSRF-token moet kortdurend zijn.

• Het CSRF-token moet onvoorspelbaar zijn. 

• Het CSRF-token mag niet binnenin een sessiecookie worden opgeslagen.

• Bij verzending moet het CSRF-token met dezelfde beveiliging worden behandeld als geheimen.

In de afbeelding hieronder wordt een voorbeeld getoond van hoe de server een verzoek zonder een CSRF-token zal weigeren.

Gebruikersinteractie

Een andere manier om CSRF te voorkomen is met gebruikersinteractie. Voordat de gebruiker iets verandert of probeert een belangrijk verzoek te doen, is interactie vereist. Een CSRF-aanval kan niet worden uitgevoerd zonder deze extra interactie. Bijvoorbeeld, de gebruiker kan worden gevraagd zich opnieuw te authenticeren of een CAPTCHA te gebruiken.

Het nadeel van gebruikersinteractie is dat het vervelend kan zijn voor gebruikers om deze extra stappen te moeten nemen. Gebruikersinteractie wordt over het algemeen alleen gebruikt voor belangrijke wijzigingen, zoals het wijzigen van een wachtwoord.

Mitigatie

Samesite-cookie

De samesite-cookie-vlag kan een CSRF-aanval voorkomen door te voorkomen dat de cookie wordt ingevoegd in het verzoek dat in een CSRF-aanval wordt verzonden. Er zijn 3 verschillende waarden voor deze vlag: none, lax en strict.

None voorkomt niet dat de cookie wordt verzonden.

Lax verzendt de cookie als je naar de site navigeert via een ander domein. Maar niet wanneer een formulier wordt ingediend.

Strict verzendt alleen de cookie als het verzoek afkomstig is van hetzelfde domein.

Headers

HTTP-headers kunnen worden gebruikt om de oorsprong van een verzoek te verifiëren. Met de referrer-header kan de oorsprong van het verzoek en de oorsprong van waarheen het verzoek gaat, worden bepaald. Als ze niet overeenkomen, kan het verzoek worden geweigerd.

Maar het vertrouwen op de headers kan problematisch zijn, omdat headers kunnen worden vervalst bij het combineren van deze aanval met XSS.

We hopen dat je genoten hebt van de blog en dat we je een stap dichterbij hebben gebracht om je meer bewust te zijn van mogelijke kwetsbaarheden en hun impact! Blijf veilig en hou ons in de gaten voor de komende blog! Ondertussen kun je onze eerdere blogs over de meest gerapporteerde kwetsbaarheden bekijken: XXS, IDOR, en SQL. 

Referenties

Hoe te code reviewen voor CSRF-problemen:

https://owasp.org/www-project-code-review-guide/reviewing-code-for-csrf-issues

OWASP’s CSRF preventie cheat sheet:

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Pinata een tool die kan worden gebruikt om een CSRF PoC te maken:

https://code.google.com/archive/p/pinata-csrf-tool

Een online CSRF PoC-generator:

https://security.love/CSRF-PoC-Genorator