CSRF Vulnerability – How It Works and Ways to Prevent It

CSRF Vulnerability – How It Works and Ways to Prevent It

CSRF or Cross Site Request Forgery lists among the top 10 OWASP vulnerabilities. A website’s trust on the browser is exploited by the vulnerability. The vulnerability harms users and can delete or modify data by using the user’s action. The attack is done in such a way that the action is performed as a valid user but he will never know that he has done something wrong. Admin’s action of the web application can be performed by an attacker, if the target account belongs to the website administrator. Reasons why this vulnerability exists on web applications is poor coding and wrong assumptions.

In this article, we understand in detail how the Cross Site Request Forgery vulnerability is exploited by attackers. We will also try and create a form, which provides a strong protection from this vulnerability.

What Is Cross Site Request Forgery Attack and How Does It Work?

CSRF is an attack in which there is a malicious action done to an innocent website from a valid user browser, when he/she runs a valid website session. And, if the user is authenticated on the website, all actions performed from the browser will belong to him. The website will also believe that the request is coming from the user’s end.

Most common results of the attack are changed passwords, purchases being made and fund transfer from bank accounts.

Mostly, the attack is performed using a third party trusted website. Fake links are posted on social networking websites and forums, which may lead to CSRF. The attack is followed by a sequence of requests and responses.

The following example explains how a CSRF attack works:

1. You log into a website http://targetwebsite.com.

2. There is a delete account action on this website through a button method. This button will submit a delete request through this link.
(form action=’http://targetwebsite.com/deleteaccount.php‘ method=’post’)

(input type=’text’ value=’Delete’ name=’delete’)

(/form)

3. The website deletes the account of the logged in user, once the button is clicked. So, the user is identified through the active session.

4. The attacker creates a fake page, which submits the form on-load. He posts the link of the page on a forum.

5. If the link is interesting, it will get clicks.

6. Once the link is clicked, the page submits the form. As you have an active session, form action will delete your account.

7. This way, your account gets deleted without your knowledge and the request has been made from your browser.

This example explains how the vulnerability affects website’s users.

Ways to Avoid CSRF Vulnerability

Checking for Referral Header

CSRF can be prevented by checking for a referral header. The request has to be blocked if it comes from some other domain, as it can be a fake request. Requests coming from the same domain should always be allowed. If the website has open redirection vulnerabilities, the method will fail. GET CSRF can be performed by attackers by using open redirection.

Captcha Verification in forms

This is another way of preventing CSRF attacks on forms. It was initially developed to avoid BOT spam in forms. But CSRF can also be prevented by it. Attacker will not be able to guess the pattern, as the Captcha is generated on the client side haphazardly. So, he will not be able to send the right Captcha with a fake request. And, Captcha verification function will block all fake requests.

Unpredictable Synchronizer Token Pattern

This is the safest method of preventing CSRF. Contradictory to Captcha verification, this method does not have to do anything with users. So, users do not realize that anything has been added to protect them. In this method, a random token is generated in each form as a hidden value. This token is correlated with the users’ current session. After submission, the web application verifies if the random token has come through a request. If yes, it needs to be verified. Through this method, developers can easily come to know if the request has been generated by a user or an attacker.



Let us know what you think