Welcome, everyone. In this post, we will look at another critical web application vulnerability. CSRF or Cross-Site Request forgery basically means that the application isn’t able to distinguish between the original request that a user sends or a forged request that an attacker makes a user send.

The most important thing about CSRF attacks is that it generally targets state-changing requests. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does.So CSRF attacks target state change on the server, such as changing the victim’s email address or password or purchasing something.

Did you ever think why do you get so many spam emails from unknown users telling you that

"You are the winner of this week's Lucky Jackpot Click on this link to get your prize money."

Most of the times it’s an attack to do malicious things without your consent. You won’t know and funds from your account can be transferred to some other’s account.

How will it affect you?

Let’s suppose you get an email from a bank XYZ in which you have your savings account. The email looks legitimate saying that there has been a change in the bank’s terms and policies. So log in to your account and read the affected changes to be in practice from today.

You will think that yes banks do care for your benefit and security and something like this can’t possibly go wrong. You go and click on the link to “See here” in your email. And with it Rs.8000 from your bank got transferred into someone else’s account.

We are just giving you an example of how Cross-Site Request Forgery works. Nowadays, security professionals are smart enough to combat issues like this that’s why technologies like One Time Password has been developed. But it’s always possible to bypass things but it takes a lot of time and patient as an attacker to break it in a possible manner.

Moreover, CSRF attacks aren’t meant for bank transactions only. A click on a malicious link and some new items might be added to your cart or removed from your cart on your favorite e-commerce site without your knowledge.
But all this is possible if the website is vulnerable to CSRF and if you are already authenticated to this site i.e. you haven’t logged out from your previous session.

How do we check if the website is vulnerable to CSRF?

CSRF is an attack that tricks the victim into submitting a malicious request. For most sites, browser requests automatically include any credentials associated with the site, such as user’s cookies. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

To understand how CSRF works, we need a tool to intercept Requests sent and their Responses. For this, we personally use Burpsuite.

Most of the times any POST request will contain 3 sections.

• Header Section
• Cookies section
• Body parameters.

Nowadays, application security is all on a whole new level and there have been many proposals on how to stop CSRF attacks. The best option that has been implemented is the use of Anti-Csrf or X-Csrf-Token in the request.

Now, what is X-Csrf-Token?

Application developers nowadays add a pseudo-random token with either every request they sent or with every session in which the user is logged in. This token is used so that the application server can identify that this token has been generated by the user’s original request and not from a forged one.

There are 3 places where the developer can add the X-Csrf-Token.
Let us look at all the 3 scenarios one by one:

• When the Anti-Csrf token is added to the Custom header:If the Anti-Csrf token is added as a custom header, the application is most probably not vulnerable to CSRF. Still, we can’t be sure just by that. So there are some other factors we need to check before confirming if the application is vulnerable to CSRF or not.

• If the Anti-Csrf token is added in the Body parameter:If the developer chose to add the Anti-Csrf token in the body parameter field, in this case also the application has fewer chances of being vulnerable to CSRF like in case 1. The factors are the same as for case 1 which we will see later.

• If the Anti-Csrf token is stored in the Cookie section:If any developer chose to add the token in cookies, in this case, the application has more chances of being vulnerable to CSRF. Now, why is that?
  Cookies are local to a user machine. If a request is sent, no matter if the token gets changed with every request or session, if it is stored in a cookie, then the attacker won’t have to worry about the token since it will be added automatically with the forged request. The attacker won’t have to think about the algorithm of token generation because every time a request is sent to that website, the browser will make sure that the cookie is sent each time.

Ok, now we have gone through the cases where the Anti-Csrf token can be added. Now as we told before, the next part covers the different parameters we need to check additionally for getting sure of a CSRF vulnerability.

How to get sure of a CSRF vulnerability?

Case 1: Perform the request without modifying anything and see the Response.

Case 2: Remove CSRF token completely and see if the response is same as in case 1.

Case 3: Modify one of the characters in the token but keep the length the same. Compare the response with the response of case 1.

Case 4: Remove the value of the token but leave the parameter in place.
What happens is the developers know to add the token but sometimes they don’t do the validation properly.
If they don’t validate properly then it’s a matter of time that the attacker may do some brute forcing and come to know the logic behind the tokens.

Case 5: Change the POST request to a get request and see if it is then vulnerable to CSRF or not.

How do attackers use CSRF vulnerability?

After finding out that this website has CSRF vulnerability, an attacker can make a link and make the user click it through a little application of social engineering. Like we said at the start of this post, about the different spam emails one gets saying “Click Here”.
This is of course not the only way. An attacker can also use a form with hidden fields as their way of performing CSRF.

This is how you can check for CSRF in a web application. CSRF is a very common attack and has been a regular in the OWASP Top 10 for quite a time. In this post, we have written everything that you need to get started. If you want to learn CSRF in depth, see the following references:

1. CSRF attack
2.CSRF Prevention Cheat sheet

Go through the references and watch some youtube videos and practice them on bug bounty targets. In the prevention cheat sheet, you will come across the different countermeasures that were taken and why they did not work. Go through that carefully. It’s important to know what won’t work than to know what will.

If you think you didn’t understand much or if the post is lacking something, don’t hesitate to comment. We will make sure to update it if required. Also in case you have some queries or missing out on something, just comment and we will always be there for your help.

Till then, happy hacking everyone.:)

‍