Cross-Site Request Forgery (CSRF): Understanding CSRF vulnerabilities

Today's estimated reading time is: 7,6 min

Last few weeks we've seen Broken Access Control vulnerabilities, how to identify + exploit various cases.In the coming weeks, we're going to dive deeper into Cross-Site Request Forgery vulnerabilities!In today's post, we will mainly focus at what CSRF vulnerabilities are and how they arise, next week will all be about exploitation!

Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that finds vulnerabilities before you do.Waitlist is open, join today ===> https://novasec.io/

Cross-Site Request Forgery:

Cross-Site Request Forgery (or CSRF) are vulnerabilities that allow attackers to conduct actions on behalf of the victimNow do not confuse this with IDORs (or BAC issues in general) as CSRF happens after deceiving a victim into clicking a malicious linkLet's take a look at a simple example to understand it even betterImagine this...You've logged into your second test accountAnd you're now testing a feature that allows you to send messages to other users and whenever you click on the "Send" button, the following HTTP request gets sent:

In the image above, we can see a GET request with 2 query parametersNow again imagine if we change those 2 query parameters' values and open the link using our first test accountCorrect, it will perform the same action but on our first account (victim), resulting in sending messages to anyone on the first test account's behalf without the victim's knowledge.Now of course this is a simple case of a CSRF vulnerabilityAnd the impact depends on how important the messaging feature wasIn some cases, CSRF vulnerabilities can even lead to account takeovers (imagine if you could apply the same method as above but change the user's email address or password!)However, the chances of finding these kinds of CSRFs are slim as most applications have some form of CSRF protectionBut don't worry about that, next week we will go over various exploitation approachesLet's first look at how you can easily identify these + how these issues often arise

Identifying CSRF vulnerabilities:

Any (privileged) function that performs some kind of action (like modification of data) can be potentially vulnerable to CSRFHowever, there are a few conditions that must be met to make it exploitable:

1. First of all, you should find a privileged action. One that can modify, add or delete data such as changing a user's email address or sending a message or even sending/verifying transactions

2. The second thing is your session ID (the ID with which a web application can verify your account and privileges) should be a cookie (with SameSite disabled) or HTTP Basic/certificate-based authentication should be used so that the browser automatically adds the authentication data to the request.

3. The last condition is that the request should not contain any kind of value that is unpredictable (such as in a query parameter or request header)

Besides these 3 conditions, there are also some other factors that play a role in whether for example, an API endpoint is vulnerable to CSRF or notBut also the request method and content type that the API accepts (this will become more clear once we start looking at exploiting CSRF attacks)Now you may think that it's super hard to find an exploitable case because of all the requirements, but understand that:

• Even if the web application only sends a specific type of request to an endpoint, it is possible that the endpoint also accepts other request methods or content types

• The request method can sometimes be overridden using query parameters or HTTP request headers

• Not every query parameter you see in a request (even the ones that have unpredictable values) is required to be supplied

• You can automate the process of crafting a working CSRF proof of concept

But again, this will become all clear in the next post when we learn to exploit and craft our CSRF payloads

Additional Resources:

• Cross-Site Request Forgery Attacks by OWASP

• A guide + labs to learn more about CSRF vulnerabilities by Portswigger Academy

• Learn more about what SameSite cookies are by MDN

• Bypassing SameSite cookie restrictions by Portswigger Academy

Don't worry, way more resources in next week's post ;)!

If you're interested in leveling-up your bug bounty gameI can help you:

• Get $200 in Digital Ocean credits to set up your Virtual Private Server for recon:

• Help automate your vulnerability and recon scans with less effort using Nova Security:

Thank you for reading this far!

I hope you've enjoyed & learned something new from this post!If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!Have a nice day and see you in the next post!You can follow me on Twitter to receive upcoming updates on this newsletter: