CSRF Attacks: How They Work and How to Stop Them

Cross-Site Request Forgery (CSRF) is one of the most common web application vulnerabilities that can allow attackers to perform unauthorized actions on behalf of a legitimate user without their knowledge. In this article, we’ll walk through a practical example of a CSRF attack using the Damn Vulnerable Web Application (DVWA), a purposely vulnerable web app often used for learning and testing security techniques. By understanding how CSRF works, you can better protect your web applications from these attacks.

What is CSRF?

Cross-Site Request Forgery (CSRF) is an attack that tricks a user into performing unwanted actions on a website where they are authenticated. The attacker exploits the trust that a web application has in the user’s browser, often by getting the user to unknowingly execute harmful requests like changing account settings or transferring money. Since these actions are taken under the authority of the user (with their session cookie), the attacker can gain full control of the user’s account.

Setting Up DVWA for CSRF Testing

To demonstrate how CSRF works, we will use the DVWA (Damn Vulnerable Web Application) which is a training ground for web application security. The first step in this process is setting up DVWA and configuring it to have a low-security level to expose vulnerabilities.

Login to DVWA
After opening the DVWA app in your browser, use the default credentials to log in: Username: admin ,Password: password
Set Security Level to Low
In the DVWA application, go to the security settings and set the security level to “Low.” This will disable several protection mechanisms, making the CSRF vulnerability easier to exploit.
Navigate to the CSRF Page
In the left sidebar of the DVWA app, locate and click on the “CSRF” link. A password change form will appear with fields for a new password and a confirmation password, as well as a submit button.

Exploiting CSRF: Step-by-Step

To demonstrate how an attacker might exploit a CSRF vulnerability, we will simulate a scenario where an attacker is able to change the password of a victim without their knowledge.

Change the Password
In the password change form, input any password (e.g., “password”) in both the “New password” and “Confirm password” fields. Once you submit the form, the DVWA will process the request, and your password will be changed. You will notice that the request is sent as a GET request with the following URL:

http://192.168.148.139/dvwa/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#

This URL contains the new password in plain text, which can be intercepted and used in an attack.

Crafting the Malicious CSRF Attack
Now that you know the structure of the GET request, an attacker can create a malicious HTML form that includes this URL. The attacker would create a fake page with a link that performs the same action without the victim’s consent. Below is the code for the malicious CSRF form (saved as csrf.html):

<!-- CSRF HTML form -->
<html>
<body>
<a href="http://192.168.148.139/dvwa/vulnerabilities/csrf/?password_new=testpassword&password_conf=testpassword&Change=Change#" target="_blank">Click Me</a>
</body>
</html>

In this form, the attacker has modified the password to “testpassword” and placed it within the GET request URL. The victim will not see any indication that their password is being changed, except for a “Click Me” link.

CSRF-Attacks-How-They-Work-and-How-to-Stop-Them-3

Sending the Malicious Link to the Victim
After logging out and logging back in with a fresh session cookie, the attacker sends the csrf.html file to the victim. The victim, unaware of the malicious intent, opens the file in their browser and sees a button that says “Click Me.”

CSRF-Attacks-How-They-Work-and-How-to-Stop-Them-4

Victim Clicks the Malicious Link
When the victim clicks the “Click Me” link, the password is changed on the server without their knowledge. The victim’s password is now set to “testpassword,” as specified in the malicious URL crafted by the attacker.

CSRF-Attacks-How-They-Work-and-How-to-Stop-Them-5

Attacker Logs In Using the Victim’s New Password
With the password now changed to “testpassword,” the attacker can log in to the victim’s account using these new credentials, thereby gaining access to their account. The CSRF attack is now complete, and the attacker has successfully hijacked the victim’s account.

How to Protect Against CSRF Attacks

To prevent CSRF attacks, web developers should implement several defense mechanisms:

Use Anti-CSRF Tokens
Each time a sensitive action is performed (like changing a password), a unique token should be included in the form or request. This token is checked on the server side to ensure the request is legitimate.
SameSite Cookies
By setting the SameSite attribute on session cookies, you can prevent cookies from being sent with cross-site requests, mitigating the risk of CSRF.
Check Referrers
Web applications should validate the Referer header to ensure that requests are coming from trusted sources.
Implementing Double Submit Cookies
This technique involves sending the CSRF token both as a cookie and as a parameter in the request, ensuring that both values match on the server side.

Conclusion

CSRF attacks exploit the trust a website has in the user’s browser. By simulating a CSRF attack on DVWA, we can see how a simple malicious link can lead to account hijacking. However, by implementing security measures such as anti-CSRF tokens, SameSite cookies, and referer validation, developers can significantly reduce the risk of such attacks. Ensuring your web application is secure against CSRF is essential for maintaining user safety and preventing unauthorized access.