What Is Cross Site Request Forgery?

ALL LINKS IN THIS ARTICLE ARE FAKE, BUT DO NOT INTERACT WITH THEM

Cross Site Request Forgery (AKA XSRF, AKA Sea Surf, AKA Session Riding, AKA Poor Man’s XSS — I made the last one up), is a web vulnerability that effects the client’s browser. An attacker will host a malicious script on a domain that they control. The purpose of the script is to make any victim that visits the attacker’s domain conduct an action on another website. For example, consider the scenario below:

Gullible Gets His Data Changed

A user named Gullible is shopping on a video game website called videogames-r-us[.]com. Gullible is super ready to buy the FINALLY released Grand Theft Auto 6, and all of a sudden someone from their gaming discord sends them this link gta-discounts[.]ec08b9g-abx920[.]dnshook[.]site. Gullible (the victim user) decides it is worth clicking on the suspicious link because he might get a discount on his upcoming Grand Theft Auto purchase. So Gullible clicks the link and is sent to the malicious website, where he is shown fake Grand Theft Auto discount codes. Analyze the image below to see the extremely real (but also fake) webpage hosting discount codes for Grand Theft Auto.

Gullible spends the next 5 minutes furiously clicking the big blue button praying that it works and he get’s a discount code, but to everyone’s suprise, it doesn’t work. When Gullible gives up and goes back to his account on the video game website, all of his billing and payment information is changed. In an insanely insecure scenario, the attacker might even be able to make Gullible pay for multiple video games and send them to the attacker’s personal shipping address. Or better yet, imagine this type of attack on your banking website. An attacker might make you send all your money, or bitcoins, to his account or wallet.

The above scenario is an example of a web attack called Cross Site Request Forgery. If you are having troubles understanding the “Cross-Site” aspect of this, think about this. The attacker hosted some code on their malicious website that automatically changes Gullible’s billing and payment information on videogames-r-us[.]com. In other words, the attacker made Gullible change his information on the video game website from a completely different website. That is why we call it “Cross Site”. This should also help you understand the “Request Forgery” aspect of this vulnerability. When Gullible used their browser to visit the attacker’s website, the attacker made Gullible’s browser make a request to the video game website. The attacker forged a request to the video game website from their own malicious website.

Why This Happens

Let’s identify why Cross Site Request Forgery happens by identifying some HTTP requests. In the following image, notice the HTTP Request and Response. A user named ‘wiener’ is logging into their account on a website, and a cookie called “session” is set for them.

This session cookie will be used for further session handling on the website, which allows the server to know which user is making a request. Take another look at session cookie that was set for the user ‘wiener’, it has a ”SameSite=None” set as a cookie attribute. This SameSite=None attribute was set by the webserver, and tells the browser “This cookie can be utilized in cross-site requests”. The SameSite can also be set to “Lax” and “Strict” in order to add some restrictions on the usage of the cookie by the browser on cross-site requests, but for the purposes of this scenario, the SameSite attribute on the session cookie will be None.

So what does SameSite=None have anything to do with Cross-Site Request Forgery? To explain that, we need some type of authenticated user action that could cause impact if exploited by an attacker. Let’s choose the action for a user to change their email address. If an attacker could make a user update their email to their own email address, the attacker could then use the forgot password functionality to change the victim user’s password because the email will then be sent to the attacker. Analyze the HTTP Request to update a user’s email address in the images below.

From the images, you can see that the action to update the user’s email address action is handled by a POST request to 0a08007f04e64ab080fadf5e005d0010[.]web-security-academy[.]net/my-account/change-email. To determine which user is making this request, the webserver only looks at ONE THING…the session cookie. And the session cookie can be used by the browser in cross-site requests (remember the session cookie has SameSite=None). This means that the action to update user email addresses for 0a08007f04e64ab080fadf5e005d0010[.]web-security-academy[.]net can be hosted on any website on the internet and the 0a08007f04e64ab080fadf5e005d0010[.]web-security-academy[.]net webserver will still update the user’s email address as long as the session cookie is in the user’s browser. This is not good because code in the page source of a website is not immediately visible when you visit the website, so your browser may be conducting actions in the background that you do not see.

So because the session cookie can and will be sent by the victim’s browser in cross-site requests, that means that the attacker does not need to guess the session cookie, or any value for that matter. All the attacker needs to do is host a form on their own domain that updates the user’s email address on 0a08007f04e64ab080fadf5e005d0010[.]web-security-academy[.]net. Let’s try this out for ourselves.

HTML Proof Of Concept

Analyze the following HTML Proof Of Concept that an attacker can host on their malicious website. When a victim goes to the attacker’s website, their email address will be changed on 0a08007f04e64ab080fadf5e005d0010[.]web-security-academy[.]net

Let’s see what happens when the victim user named ‘wiener’ visits this page. For referrence, I will include 3 images that show the victim’s email address being changed after they visit my malicious webhook.site address.

As you can see in the sequence of images above, the victim’s email address was changed after visiting the attacker’s malicious website.

The main idea behind Cross Site Request Forgery is that the victim user does not intend to make the request, but the browser makes the request for them anyways. So a common defense developers use against Cross Site Request Forgery is security tokens. The idea of the security token is that the token is generated for the user’s account whenever they make sensitive, authenticated requests (like changing their email address). The server uses the security tokens to verify that the user did in fact make this request and therefore does want to take this action on their account. Without the security tokens, the request to change the user’s email can come from any domain, whereas with the security token protection in place, the request should only come from the server where the token was generated. This security token protection aims to help the server determine if a user actually intended to take an action on their account.

While security tokens are a protection against Cross Site Request Forgery, sometimes these protections are not implemented correctly. For example, let’s look at an example where security tokens are required for POST requests to change email addresses, but NOT required for GET requests to change email addresses.

Incorrectly Implemented CSRF Security Token Protection

Analyze the HTTP Requests below that change the user’s email address

Notice that the above POST request requires a token called “csrf”, which is how the developers are implementing security token protection against Cross Site Request Forgery. The idea is that the csrf token in the request is only be generated on the 0afe00e80438e76787f7209f00ec00d2.web-security-academy.net domain. So even if an attacker hosted a form on their website that attempts to change a user’s email address on 0afe00e80438e76787f7209f00ec00d2.web-security-academy.net, the request would not be successful because the csrf token will not be sent with the request, as it’s not generated on the attacker’s malicious domain. A user’s csrf token cannot be predicted by attackers, so it is considered a protection against malicious cross-site requests.

However, in this scenario, the csrf token is only required when making POST requests that change user email addresses. Users can still use GET requests to change their email address, and there is no csrf token validated against GET requests to change user email addresses. Analyze the images below where a user changes their email address with a GET request that does not require the csrf security token.

This means that in order to make a user change their email address on 0afe00e80438e76787f7209f00ec00d2.web-security-academy.net, an attacker can still host a form that utilizes a GET request instead of a POST request, and they will not need to include a csrf token in the forged request on their malicious domain. Let’s test this out. I will host the GET request form shown below on a domain I own, and when the victim visits it, their email address will be changed. Here is the form I will host on my malicious domain.

Analyze the sequence of images below to see a victim user visit a malicious domain and then their email address is changed, once again.

Cross-Site Request Forgery (CSRF) is a vulnerability that allows attackers to trick users into performing unauthorized actions on their accounts without their knowledge. Unlike Cross-Site Scripting (XSS), which lets attackers inject arbitrary JavaScript into a user’s browser session, CSRF doesn’t require the attacker to exploit the target site’s script execution mechanisms. Even if a website is secure against XSS, it could still be vulnerable to CSRF, allowing attackers to perform actions on behalf of an authenticated user.

CSRF primarily impacts the Integrity aspect of the CIA triad. When a victim is deceived into making authenticated requests to one website (Website A) while browsing another (Website B), the data integrity of Website A is compromised. This can lead to unauthorized changes, leaving users and administrators uncertain about the trustworthiness of their data.

Mitigating CSRF is crucial to safeguarding user data and maintaining trust. Without adequate protection, your users’ personal information and your business reputation could be at significant risk. Implementing CSRF defenses, such as anti-CSRF tokens, SameSite cookies, and secure authentication mechanisms, ensures robust protection against this insidious vulnerability.

Thanks for reading, and if you learned something, THANK YOU FOR LEARNING!

Check out my other articles below, say Hi in the comments, and click that clap button for me, or maybe I’ll just make you do all those things with some request forgery =)