What is Cross-Site Request Forgery?

Author: Jayson Zabate

Senior Security

Consultant – Offense Team
In this article, we’ll explain what cross-site request forgery is, describe some examples of common CSRF vulnerabilities, and explain how to prevent against CSRF attacks.

Cross-site request forgery (also known as CSRF, Sea Surf, or XSRF) is a web application security vulnerability that allows an attacker to force their victim (authenticated users) by sending a link through a message or email to submit a request to a web application against which they are currently authenticated. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.

How does Cross-Site Request Forgery work?
Figure 1: CSRF attack

An attacker’s aim for carrying out a CSRF attack is to force the user to submit a state-changing request.

Examples include:

  • Account Take Over.
  • Change User Details or Password.
  • Submitting a Transaction or Payment.
  • Deleting Records.
CSRF Attack Example

Before executing an attack, a pentester typically studies an application in order to make a forged request appear as legitimate as possible.

State-Changing Actions

There is a state-changing action within the target applications that the attacker has reason to exploit. It could be any action specific to the user account. For example, sending email from ticket support page and modifying user settings are both state-changing.

Lack of CSRF Protections

Using Burp Suite check all the requests in HTTP History and check if there is CSRF token or any validating methods in the Application Header and POST / GET Body.

While you’re actively finding for CSRFs. Keep analyze the application until you encounter the request associated with the state-changing action.

For example, there is no mitigation of Cross-Site Request Forgery on the request and the change password function you discovered is vulnerable to CSRFs.

Figure 2: Burp Suite Proxy – HTTP/HTTPS Request
Confirm the CSRF vulnerability

The attacker generates a Cross-Site Request Forgery (CSRF) exploits for the vulnerable website and hosts it on a web server under their control.

The attack could be delivered in a <form> tag with automatic execution of the embedded payload.

This is how such a form may look like:

Figure 3: POC – CSRF exploit

Next, attacker can force user to visit the malicious site via email. Those who click on the link while logged into their account the vulnerable website will process the request as if the victim made it, and execute the state-changing action their account.

Bypassing CSRF Protection

Using Cross-site Request Forgery Tokens allow the server to uniquely distinguish who actually requests the resource or action and to protect your server call from CSRF/XCSRF attack and other vulnerabilities. However, the following common implementation weaknesses enable attackers to bypass security:

Removing the Anti-CSRF Token

By removing the token on the request, you might be able to get the action executed without encountering CSRF protection.

For example, the POST request of the password-change endpoint is protected by a CSRF token, like this:

Screenshot 1: Original Request from vulnerable application

Remove the token on the request and Create CSRF payload

Screenshot 2: Edited Request from vulnerable application

In this case, your malicious page could simply look like this:

Proof of Concept: Removing the anti-CSRF token

Change the Request Method

Using Burp Suite send the request on the repeater tab and use “Change request method” on the context menu to convert it into a GET request and observe that the CSRF token is no longer verified.

For example, Change the POST request of the password-change endpoint into GET request and remove the token, like this:

Screenshot 1: Original Request from vulnerable application

Screenshot 2: Edited Request from vulnerable application

In this case, your malicious page could simply look like this:

Proof of Concept: Changing the request method

Using the Attacker’s Anti-CSRF Token

The CSRF token is valid on the application but does not check which user the token is associated with, an attacker is able to provide their own CSRF token to satisfy server requests check and bypass the CSRF protection.

The csrf_token in the user’s request is already implemented. However, it is possible to attacker to use their own csrf_token and force the user to change the password of account.

Proof of Concept: Using attacker’s anti-CSRF token

Bypass CSRF Referer Header Check

The target site is not using CSRF tokens but checking the referer header instead. Many applications validate the Referer header when it is present in requests but skip the validation if the header is omitted.

Since the application validates the referer header try to remove the header on the request. and use a <meta> tag to the page hosting your request form.

Proof of Concept: Removing CSRF Referer Header
Self-Stored Cross-site scripting using CSRF attack

The attacker can combine self-Stored Cross-site scripting with CSRF form. For example, we have the application called theos-cyber.com and its give the user to make a username for his account.

However, the affected endpoint used to change the username is vulnerable to CSRF and self-XSS

Screenshot 1: Origin request – vulnerable to CSRF and Self-XSS

This request will change the victim username and stored the XSS payload there. When the user’s logs into the account and views their profile, the cross-site scripting will execute the on the victim page.


The best way to protect your code against CSRF attacks is to include a CSRF token within relevant requests. The token should be:

  • Unpredictable with high entropy, as for user session tokens in general.
  • Strictly validated in every request of the user action before the relevant action is executed. If they do not match, the request is dropped.
  • Referer-based defenses against CSRF

Use the SameSite Flag in Cookies. It is a new method to protect your application from CSRF attacks and improving web application security.

If the session cookie is marked as a SameSite cookie, it is only sent along with requests that originate from the same domain.


The CSRF attack demonstrated above shows applications are intrinsically vulnerable to CSRF because they are automatically sent with each request. This allows attackers to create malicious script and force the user to change their details.

Get in touch