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?
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.
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:
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.
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.
Recommendation
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.
Conclusion
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.
