💁♂️ CSRF
CSRF is an attack that tricks the victim into submitting a malicious request.
What is Cross-Site Request Forgery (CSRF)?
Cross-Site Request Forgery (CSRF) is an attack that tricks users of a web application into unknowingly performing unwanted actions while they are authenticated. This type of attack targets requests that change the application’s state, rather than stealing data. Because the attacker cannot see the response to the forged request, they rely on social engineering techniques, such as sending malicious links via email or chat, to deceive users into executing actions of the attacker’s choosing.
Impact of CSRF attacks:
If the victim is a regular user, a successful CSRF attack can lead to state-changing requests being performed without their consent. This can include actions like transferring funds, changing their email address, or giving an attacker access to their data. On the other hand, if the victim has an administrative account, a CSRF attack can compromise the entire web application.
Understanding CSRF Attacks
Cross-Site Request Forgery (CSRF) attacks allow attackers to bypass authentication processes or perform actions with elevated privileges. To execute this type of attack, the attacker must:
- Create a custom payload.
- Embed the request into a hyperlink.
- Trick the victim into clicking the link, which sends the request to the website.
- Forge the request to conduct malicious actions.
CSRF attacks only work if the victim is an authenticated user. This is because, when the request is made, the application checks if valid session cookies are available. If relevant cookies are available and sent with the request, and the website approves them, the CSRF attack will be successful.
CSRF Attack Example
Let’s say that a user is logged into their bank account and wants to transfer money to another account. The user’s bank uses a GET request to transfer funds, which is vulnerable to CSRF attacks. The attacker creates a malicious link like this:
https://bank.com/transfer?to=attacker&amount=1000
when clicked, transfers money from the victim’s account to the attacker’s account. The attacker then sends the link to the victim via email or chat. If the victim clicks the link, the request is sent to the bank’s website, which approves the request because the victim is already authenticated. The attacker receives the money, and the victim is none the wiser.
If the attacker is sending the payload with a POST request, a payload similar to the following HTML code can be used:
<html>
<body>
<form action="http://bank.co m/transfer" method="post">
<input type="hidden" name="Transaction" value="withdraw" />
<input type="hidden" name="Amount" value="3000000" />
<input type="submit" value="Click"/>
</form>
</body>
</html>When using the “bank.com/transfer” endpoint to perform a transfer action, the “Transaction” and “Amount” parameters are passed via a POST request. Since this endpoint doesn’t require a random CSRF token, an attacker can put HTML code on “attacker.com,” send the link to the victim, and initiate a transfer once the victim opens the link. This attack is possible due to the lack of mandatory CSRF token.
what is CSRF token?
A CSRF token is a unique, secret, unpredictable value that is generated by the server-side application and transmitted to the client in such a way that it is included in a subsequent HTTP request made by the client. When the later request is made, the server-side application validates that the request includes the expected token and rejects the request if the token is missing or invalid.
is CSRF simple as it looks?
When the victim opens the link, the transfer occurs. Right?
Well, it’s not that simple.
There are various scenarios to consider. For instance, if the victim is using Chrome browser, it won’t work. However, if they are using Safari, it would work. So, can we conclude that CSRF doesn’t occur in Chrome anymore? No. It depends on whether the victim logged in to bank.com within the last two minutes. If they did, the transfer will work. If more than two minutes have passed, it won’t.
Furthermore, whether the “bank.com/transfer” endpoint accepts the content-type as “text/html” determines whether it will work or not. If it only accepts “application/json,” it won’t work.
I understand that it may be confusing. To understand these scenarios, we must first grasp two concepts: SameSite Cookies and Same Origin Policy. Let’s break it down step by step.
SameSite Cookies
SameSite is a cookie attribute, similar to HttpOnly and Secure. Its purpose is to address the main vulnerability exploited by CSRF attacks. By default, when you send a request from a.com to b.com, the browser includes your cookies for b.com in the request. As a result, when the attacker’s code on evil.com sends a money transfer request to bank.com, the browser sends an authenticated request to bank.com, leading to the successful transfer.
If the browser fails to add the cookie to the request, it poses a problem. Let’s consider a scenario where a victim logs in to bank.com, then visits evil.com. Inside evil.com, a transfer request is sent to bank.com. However, because the browser doesn’t include cookies, the request lacks the necessary authentication, resulting in the transfer not taking place.
To address this issue, a concept called “SameSite” has been introduced. The SameSite cookie attribute offers three possible values:
Lax: Cookies are not sent with normal cross-site requests, unless the user is navigating to the original site (e.g., by following a link).
Strict: Cookies are only sent in a first-party context and are not included in requests initiated by third-party websites.
None: Cookies are sent in all contexts, regardless of whether the request is cross-site or first-party.
Developers have the option to set Lax or Strict flags as protection against CSRF attacks. However, what happens if they neglect to do so? Let’s refer back to our previous example:
"if the victim is using Chrome browser, it won't work. However, if they are using Safari, it would work."
The reason behind this is that the Chrome browser automatically applies a default SameSite value (Lax) to cookies. As a result, even if the developer is unaware of CSRF or SameSite cookies, their websites are still safeguarded, and CSRF attacks are prevented. Let’s put this to the test.
Using the Chrome browser, navigate to https://authenticationtest.com/simpleFormAuth/ (opens in a new tab) and complete the form by entering the provided username and password values.
Once logged in, the application will generate a session cookie. You can verify its presence in Chrome’s developer console. Notably, the cookie does not contain a SameSite attribute.
There is a form that we can test at https://authenticationtest.com/xssDemo/ (opens in a new tab) . Just fill the textbox and click the “Search” button. It generates a POST request and the request doesn’t contain a random CSRF-token. So in theory, we can conduct a CSRF attack there.
Save the following HTML snippet as csrf.html and open it in the same Chrome browser that you logged in.
<html>
<body>
<script>history.pushState(‘’, ‘’, ‘/’)</script>
<form action=”https://authenticationtest.com/xssDemo/" method=”POST”>
<input type=”hidden” name=”search” value=”requestTest” />
<input type=”submit” value=”Submit request” />
</form>
</body>
</html>Open Chrome’s developer console and go to the “Network” section. Then, click the “Submit Request” button. what happened? the POST request sent with our authentication cookie.
Was that wrong? Does Chrome not always set the Lax attribute? If it doesn’t, then this request shouldn’t have the cookie.
Now things get a bit tricky. Let’s remember what I showed you earlier:
“If the user logged into bank.com just 2 minutes ago, the CSRF attack will work. But if it’s been more than 2 minutes, the CSRF attack won’t work.”
Basically, Chrome only sends the cookie within 2 minutes of authentication; after that, it stops sending it.
Please wait for 2 minutes before resending the request using csrf.html. Notice any changes? This time, the request doesn’t include the cookie.
why there is such a behavior? When Chrome started to set SameSite attribute to Lax by default, it caused issues with certain aspects of the web.
Certain applications like OAuth, OpenID, and payment gateways depend on cross-site requests for their functioning. Without this capability, the entire process breaks. To address this, Chrome developers introduced a temporary solution known as the “2-minute rule.” This rule allows these processes to operate smoothly. However, it’s important to note that this solution is only temporary, and the upcoming change will make SameSite=Lax the default setting for all scenarios.
So, if the victim uses a Safari browser and the “bank.com/transfer” endpoint doesn’t require any CSRF tokens, we can exploit it, right.
Well, it’s not that simple.
Same Origin Policy
I won’t get into all the technical details of the Same Origin Policy, as it can be quite complex. Instead, I’ll talk about how it relates to CSRF and clear up a common misconception:
Some folks think the Same Origin Policy only stops “a.com” from grabbing data from “b.com,” but lets requests from “a.com” go to “b.com.”
Actually, that’s not entirely correct. The SOP mostly stops data reading, but sometimes it also limits sending data.
So what kind of requests are allowed?
It allows sending GET/POST requests through HTML forms. Let’s try the following example:
<html>
<body>
<script>history.pushState(‘’, ‘’, ‘/’)</script>
<form action=”https://example.com/" method=”POST”>
<input type=”hidden” name=”amount” value=”500" />
<input type=”submit” value=”Submit request” />
</form>
</body>
</html>Request’s content-type will be “application/x-www-form-urlencoded” which is allowed by SOP. Therefore, the request is sent.
This feature prevents PUT requests as well as requests with the “application/json” Content-Type header.
You cannot initiate PUT or “Content-Type: application/json” requests using HTML forms. Instead, these require a distinct approach known as a “special request.” To accomplish this, you can employ the XMLHttpRequest (XHR) method in JavaScript. Let’s explore an illustrative example below:
<!DOCTYPE html>
<html lang="en">
<body>
<script>
var xmlhttp = new XMLHttpRequest();
var theUrl = "https://mychaos.me/transfer";
xmlhttp.open("POST", theUrl);
xmlhttp.setRequestHeader("Content-Type", "application/json;charset=UTF-8");
xmlhttp.send(JSON.stringify({ "amount": "500" }));
</script>
</body>
</html>The above code will send a POST request to the “https://mychaos.me/transfer" (opens in a new tab) endpoint with the “amount” parameter set to 500. The request failed due to “CORS error”. So, what happened behind the scene?
Since this is an XHR request, the browser sends a “preflight” request to the target website with “OPTIONS” method. The browser makes this request to understand if the target website allows this request. How a website can allow this request? With Cross-Origin Resource Sharing (CORS) header of course. If the target website had “Access-Control-Allow-Origin: *” response header, the request would be successful.
So, we can say that:
- If the “bank.com/transfer” endpoint only accepts “application/json” content-type, it doesn’t need any CSRF tokens. The attack won’t work.
- If the “bank.com/transfer” endpoint only accepts “PUT” requests, it doesn’t need any CSRF tokens. The attack won’t work.
But of course, we shouldn’t forget that there might be wrong implementations on the code base. What if “bank.com/transfer” accepts GET requests as well mistakenly? We can exploit it with:
<img src=”https://mychaos.me/?amount=500">img or script don’t require preflight requests.
Conclusion
Cookies are vulnerable as they are automatically sent with each request, allowing attackers to easily craft malicious requests leading to CSRF. Although the attacker cannot obtain the response body or the Cookie itself, the attacker can perform actions with the victim’s elevated rights. The impact of a CSRF vulnerability is also related to the privilege of the victim, whose Cookie is being sent with the attacker’s request. While data retrieval is not the main scope of a CSRF attack, state changes will surely have an adverse effect on the web application being exploited.
Written by Mohsine El Hadaoui (opens in a new tab)