I usually encounter a discussion with software development teams regarding a Medium risk defect finding – Cross-Site Request Forgery (CSRF). A medium-risk would mean persistent attempts may lead to a compromise. The prerequisite for launching a CSRF is quite complicated. I am always bombarded with so many questions and disputes on why we flag this defect.

The Danger

In a nutshell, CSRF is an attack that leverages trust. Burp Suite (Portswigger) explains it in detail. Imagine a phishing email enticing to click on a link that will redirect you to a website you supposedly wanted to visit. But upon clicking, the link triggers a transaction from a website where you have an active session with values on all parameters preset. Without you knowing and without any credentials stolen, a transaction is successfully executed.

An example simulation is shown below using a DVWA (Damn Vulnerable Web Application) and Burp Suite (proxy tool).

In this scenario, the attacker’s target is to be able to change the password of the account in DVWA by setting values on the parameters on the change password function. The victim does not have to go to that specific page. He/she only needs to have an active session when the phishing link is clicked.

When we said the request to the proxy, a GET request to the server looks like this:

The highlighted portion contains the parameters such as the password_new (New Password) and password_conf (Confirm New Password), and Change (Change Password Action). Assuming that the attacker has an idea on this specific request, he can create a prefilled transaction that he will use in his phishing email.

Burp Suite Pro has a Generate CSRF POC feature that will create the transaction:

You can then put the values in the parameters of the change password function. In this simulation, we changed the password to ‘test.’ The parameters and values are highlighted below:

You can test the Generated POC in the web browser. It will be loaded in the browser, similar to a link that you will include in a phishing email.

When you click the button and send it to the proxy tool, you will see the CSRF POC that we created, and the server with a legitimate request will accept it.

The application will tell you that the password has changed.

When validated during a new session (logout then login), the new credentials are accepted.

That’s how the usual CSRF attack will look like. What are the issues then, and why are there discussions on CSRF attacks’ relevance with the development teams?

The Practicality

In the simulation shown in the first part, there are a lot of assumptions.

1. The assumption that the user has an active session

We are assuming that the user is currently using the session that we are targeting to exploit. Even if the user clicks the link, but the session is not active, the attack will not be successful.

2. The assumption that the user will fall for the phishing email and click the link

We are also assuming that we can lure the user into clicking the link.

3. The assumption that 1 and 2 are happening at the same time. This is self-explanatory. They need to co-exist so that the attack will be successful.

The developers, project managers, or even application owners’ argument is the practicality of the CSRF. As mentioned in the introduction, this attack leverages trust, and there is no single successful formula in exploiting the user’s trust. So with a valid argument from the developers, why are we still flagging it as a defect?

The Judgment 

The rating that is given for each defect depends on its severity. Even if there are so many assumptions and prerequisites before successfully launching the attack, the application is still at risk with CSRF. The probability that it will always happen is still there. On the side of security, we know that it is easy to launch an attack; therefore, we say it is medium. It means that persistent attempts may lead to compromise.

Furthermore, security best practices will tell you that CSRF can be mitigated through the code-level layered defense. One of the best mitigations is deploying an Anti-CSRF token generated by the server that the application will use for validation when a transaction is executed. Burp Suite (Portswigger) has a good article about CSRF Tokens.

Here is a code snippet from a remediated change password function in DVWA. It will show you that there is a token validation to the server to check if the user intentionally made the request. At the end of the code, you will see that a generate token function is called to be used for the next transaction.

Conclusion

CSRF attacks are prevalent in applications, and at the same, it is not easy to exploit. However, the security tester’s role is to exhaust all possible ways of controlling the application and checking if there are ways to improve its security. Thorough CSRF checks are done in the admin panel, where a lot of CRUD actions are done with an escalated privilege (such as admin or super admin). Once the defect is exploited, it is imperative that remediation activities be done in the soonest possible time.