Hello Hackermen, it’s about time we updated our Knowledge Arsenal. And here I have a really interesting concept or as you’d say Hack for you guys, Cross Site Request Forgery(CSRF). Well, we can basically use it to make can be anything from changing their username to birthday. We can also possibly change the password or email and take over the account! Sounds fun, right? So enough of the small talk, let’s just dig right in instead. Get in your Stealthy Hoodies with that Hacker Mindset and here we go..!

Disclaimer : Everything mentioned in this article is purely for Educational Purposes. Performing the same practically without consent is considered and could land you up in jail. The HackrSpace is strictly against such malformed practices and won't be responsible for anything Unethical you might do with the shared knowledge.

Hmm, CSRF? Say What?

According to wiki, “Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser.”

According to Owasp, “Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.”

Still confused? Simply put, CSRF allows us to make someone perform some changes(Actions) on a particular Web Application. (This is usually through some kind of Social Engineering). It targets State Changing Actions like changing your profile username, updating your password or transferring money to a bank account. And moreover, in addition, all of this happens in the background. Thus, the poor ignorant victim, is still all happy and gay. And by the time they realize, it’s all too late.

Why does it happen tho?

Basically, it abuses the trust relationship between the victim’s browser and the web server. CSRF somewhat evades the Same Origin Policy(SOP), which is in place to prevent different sites from interfering with each other. A malicious website sends a request to a web application that a user is already authenticated to, from a different website.

Now let me explain that a bit. Let us consider Twitter for example. How many times do you login to the application? Do you need to enter your credentials every time you want to make a tweet or like something? No, right! ( Oh, can you imagine how messy it’d be if you have to?🤯) So, let’s say you like a post, how does twitter know that it is in fact you? It didn’t ask for the password again right? The answer to this is Cookies. Once you login and authenticate to the site, it (in most cases) sets 1 or more cookies in your browser. These cookies contain your Session details. Hence, they can uniquely identify you as the user. As a result, after logging in, the Browser sends those cookies with every later request. Thus, you don’t have to login every time to do some action on the site.

Concluding, let’s say that the web app relies only on cookies to identify the user. It has some interesting actions (from the attacker’s perspective) to perform. Has no unknown values for any parameter (Eg. No 2FA or confirmation emails). And the victim is already authenticated to the target website. Here, CSRF might be possible. Curious how? See through!

But tell me how does it work?

Finally, time for the Technical Details.

POST Based CSRF

Here in this example request, you can see that the web app uses only the Session cookie to keep track of the user. Furthermore, there are no other tokens or unpredictable parameters as well. Thus, this makes it a perfect candidate for a CSRF attack.

The HTML form the attacker will create to exploit the CSRF here would be something like this:

<html>
  <body>
    <form action="test.com/email/change-email" method="POST">
    <input type="hidden" name="email" value="[email protected]"/>
    <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

The attacker, with the help of some Social Engineering, will then lure the victim to execute the HTML form in their browser. Eg. Make the victim visit a Webpage controlled by the attacker where they have embedded the HTML code on their site.

As a result, as soon as the victim visits the Attacker controlled domain, the HTML request gets executed from the Victim’s browser. As the victim is still logged in to test.com, the session cookies are automatically sent with the request.

And guess what?

The victim’s email id changes to [email protected]. The best part? They don’t even know what happened!

The Complete Scenario would be something like this:

1. Victim submits his log in details to test.com.
2. The Server authenticates the request and sends back a Session Cookie in the response.
3. Browser stores the cookie and the victim is logged in.
4. While still logged in, the victim then visits the evil site which contains the CSRF HTML form.
5. Now, the form executes in the Victim’s browser and it even sends the session cookies along with it.
6. Thus the Server recognizes it as a valid request made by the Victim and accepts it.

GET Based CSRF

http://bank.com/transfer?amount=10000&account=bob

<img src=http://bank.com/transfer?amount=10000&account=tom/>

CSRF Prevention Mechanisms

The core concept in preventing CSRF is to add or do something extra with the requests, which the attacker cannot guess and the server validates.

There are a lot of proposed solutions for preventing CSRF issues but not all of them are worth it or can be a pain to set up. So, here we will see some of the most effective and common solutions in place now-a-days.

CSRF Tokens

This defense is one of the most popular and recommended methods to mitigate CSRF. These are also known as Anti-CSRF or Synchronizer Tokens. Let’s see how it works.

• The Server generates and stores the Token
• The same token is sent back to the Client and the Client Browser stores it
• The Browser sends that Token with the form as part of the POST Request body, in a hidden form field.
• The Server checks if the token in request matches the value it had stored on itself
• If both values match, the server processes the request
• If they don’t, the server simply discards the request

Since the attacker has no way to know the value of the hidden form field, he can’t perform a CSRF attack.

Same Site Flag in Cookies

SameSite is a cookie attribute (similar to HTTPOnly, Secure etc.) which aims to mitigate CSRF attacks.

For the most part CSRF only works as the browser sends cookies automatically with every request. But it is important to note that the Browser only sends cookies related to the same Request Origin due to the Same Origin Policy. Eg. Even if test.com and hack.com are open in the same browser, only cookies with origin related to test.com will be sent to test.com. And same for hack.com. Browser does not send test.com cookies to hack.com or vice versa. But that said, let’s say test.com contains some code to make a request to hack.com. In that case, even though the request originates from test.com, The browser performs that request to hack.com and thus sends the cookies as well (Cross site). And that is the main reason to why CSRF exists.

So, to prevent that, a flag is available which turns the normal cookie into a Same Site Cookie. A same-site cookie is a cookie that can only be sent if the request is being made from the origin related to the cookie (not cross-domain). The Cookie and the page which makes the request have the same origin if the protocol, port (if applicable) and host is the same for both. Thus, preventing any Cross Domain Requests.

Before you go…

And here, TheHackrSpace concludes Cross Site Request Forgery(CSRF). There are tons of articles and blogs out there. In fact so much information is available that it instead confuses you on where to start or look for! So here, I tried to explain everything as simply as I could while still keeping it as plain and short as possible. Hopefully you’ll have something to take off from here! Nonetheless, take this moment to pause for a second and Congratulate yourself. You just learned something new today. You’re already a better version of yourself than you were yesterday, Awesome! Remember, 1 step at a time 😀

Also note that, Obviously, there’s numerous ways to try and bypass these and other protections in place preventing CSRF. But that said, It’d be out of the scope of this article and seems a good fit a whole other topic in itself. So let’s keep it for some other time 😉. Lastly, as a reference and to practice your newly gained Superpower, I highly recommend checking out Portswigger Labs (not a promotion, it’s actually worth it!). It’ll give you a real life idea on exploiting CSRF. So, go check them out!

So finally, Goodbye? Umm…Well, seems just fair to compensate with a little something to make up for this delay in getting back to you guys. What do you say?😏

What..!!? A Bonus…?!!

From now onward along with trying to update TheHackrSpace regularly and keep the knowledge flowing, I’ll also try to provide you with my personal notes I’ve made along the way as well! But keep in mind that the notes are going to be completely RAW. As that was supposed to only be referred by me. So, if you have a hard time understanding, my apologies 😛 Here’s the link to it: WebSecDiary

So, that’s it for now then. Stay tuned , for there’s much more good stuff coming your way! Until then, check out the Hacker Journal!

Finally, Thank You for all the support and Keep Hacking <3 TheHackrSpace, signing out.