CSRF to Account Takeover, the conceptual way of bug chaining.
This is my take on CSRF and how to understand and chain them with different bugs when you are just starting in the Web Application Penetration Testing.
The process to analyze or understand any vulnerability:
1. What it is?
2. Why it exists (basic and specific reasons)?
3. Impacts (the damage it can cause)
4. Mitigation (ways to prevent it)
Description:
What is CSRF?
It stands for Cross-Site Request Forgery and lies under the category of Client-Side attacks in the Web Application Penetration Testing domain. It occurs when two of the most important policies for the security of the website/applications are not implemented properly i.e.; SOP (Same Origin Policy) and CORS (Cross-Origin Request Sharing).
Now in order to understand the concept of CSRF let’s understand these policies and how an attacker can bypass them by performing a successful CSRF attack.
Same Origin Policy:
First of all, let’s go through the term ‘Origin’. It is determined by 3 things:
1. The Protocol (HTTP, HTTPS)
2. The Host (for example, www.abc.com)
3. The Port Number (80, 443 in the case of HTTP and HTTPS)
Now, the SOP determines that how documents are allowed to interact with resources (images, videos, etc.) and these resources will only be available to the URLs that belong to the same origin i.e. they need to satisfy the checklist of the term ‘origin’. It prevents other malicious websites to read or access resources of any legit website.
For example, when you have visited www.malicious.com and request a GET request to www.example.com/profile, for your browser the SOP will stop www.malicious.com from studying the responses from www.example.com/profile. However, www.example.com may also permit different websites to have interaction with it in cross-origin. Nonetheless, that is commonly restricted to certain websites and unrestricted interaction is never recommended. This policy is enforced by the browser itself and the only exception to this is the infamous Internet Explorer.
Cross-Origin Resource Sharing (CORS):
This policy was specifically designed to relax the SOP due to its strict nature and as the name suggests it is used for other websites (with permission) to share or access resources from another website.
For example, let’s suppose that website abc.com wants to fetch data from xyz.com then A will ask for a resource using the pre-flight (described below) request and xyz.com will send a header called “Access-Control-Allow-Origin: abc.com” saying that whenever you (abc.com) will request something from me (xyz.com) keep this “Access-Control-Allow-Origin: abc.com” option with you in the request header.
Pre-Flight request: It is used to check if CORS is allowed on a particular website/application or not and that the server also understands the use of certain headers and methods used to implement CORS.
Let’s come back to CSRF now, how do these two policies fit in with CSRF? It’s pretty simple, this vulnerability comes into existence when an attacker tries to fetch a user’s information (resource) from a target website using their own malicious website and in some cases to perform an unintended action from the victim’s side resulting in loss of sensitive data.
For example, password change, money transfer, e-mail update, etc. The list just goes on, it depends on the creativity of the attacker and their motive.
However, if we talk in technical terms then suppose a scenario where you own the malicious website evil.com and you know that the website abc.com is vulnerable to CSRF attack and Peter is your victim. Now, in order to exploit it you need to follow the described steps:
1. Craft a malicious link to your website that contains the code to be executed once Peter visits your website.
2. That code will send a request from evil.com to abc.com via Peter’s browser and that request will ask abc.com to perform a certain action, let’s say change password request on behalf of Peter.
3. “abc.com” will receive the request and because there is no CSRF-Protection so, this site will certainly allow the action to be performed.
Note: In order to successfully execute it or test it, the victim user must be logged in on the website that is vulnerable to CSRF.
Example:
In this scenario, I exploited the CSRF and performed certain actions on behalf of the victim account in order to gain complete control of the account.
Vulnerable URL: cannot disclose due to confidentiality. Let’s call it abc.com
Severity: High
Vulnerability Name: CSRF to account takeover
Description:
1. Initially I made two accounts on abc.com (Victim and Attacker)
2. Then I logged in with both the accounts on two browsers (chrome and safari) then went to the change password option on https://www.abc.com/en/uos/account/password
3. Now, I captured this password change request using BurpSuite’s Interceptor and sent it to the Repeater then I went to engagement tools and generated a CSRF POC (Burp Pro only).
4. After this, I sent this request of “Change Password (containing new password decided by me, therefore, unintended action)” to the Victim’s account on safari, and once that request was being sent from the victim’s browser, Voila!, victim’s password was successfully changed and I was able to login from Victim’s account on my Chrome browser.
There is more to CSRF attacks and their potentials like there are different methods to perform them via GET and POST but because I want to keep this post Beginner and Concept friendly, that is the discussion for another day.
Impact:
I think we have covered some of the Impacts of CSRF and also seen an example of how it can be exploited in order to gain account control but there is more so, let me just put a little list for you guys:
1. Execution of fraudulent transactions
2. Account takeover
3. Execution of unintended actions
4. It could trigger XSS (refer to this https://hackerone.com/reports/177508)
5. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application.
Mitigation 1:
The first and foremost mitigation that I would like to discuss is the Same Site Cookies because this is a relatively new method as compared to the traditional Anti-CSRF Tokens. Same Site Cookies are a little different than the traditional HTTP cookies as their name suggests they are of the Same Origin and they could only be sent when the request is sent from the same origin and is associated with that cookie.
For example, the cookie and page from where the request originates and can be said to be of the same origin (see above for an explanation of the term ‘origin’). Nevertheless, this method is unorthodox and will take some more time to be implemented as some browsers don’t support the web apps that use the same site cookie yet.
Mitigation 2:
Furthermore, there is one more way to prevent CSRF (the traditional way) and that is by using Anti-CSRF Token. Now, what is this token? Let’s have a look:
They are generated by the server of the web application and must be unpredictable and they allow users to perform any actions only after proper validation of the token.
The server generates two tokens and ties them with the response in the cookie and in the form itself. So, whenever the user will submit the “HTML Form” then both of these tokens will be sent back to the server. One is tied with the form (sent by the browser) and another one is sent in the cookie (by the client).
However, if both of the tokens are not sent then the server will disallow the request. There’s one more catch to it; the token must be tied to the user’s session and must expire after some time (for example, when the user logs out) otherwise it could be stolen and then lead to a CSRF attack.
For Practice:
Hey, if you are done reading and want to practice the concepts that you have learned just now then I would suggest PortSwigger labs. These labs will give you an understanding of the Basic CSRF and also the implementation mistakes that we see when the Anti-CSRF token is not configured or validated properly.
