Sign in Subscribe
Bug Bounty

CSRF in Bug Hunting

ayush khatkar

• 5 min read
CSRF in Bug Hunting

Cross-Site Request Forgery, or CSRF, is a technique that an attacker can use to alter user data, passwords, and other information without the user's knowledge. The attacker's goal is to fool the user into clicking a link even if they have already authenticated with the application using their browser.

Assume there are two users. Bob is the victim, while David is the assailant.

In this case, Bob had already registered and created an account on reacted.com through his browser. As a result, when Bob visits that website through his browser, it will not prompt him to enter his username and password in order to log in again.

All that a cookie is is a 4KB file that gets saved in your local browser and is used to store information unique to the user, such as preferences, session IDs, and goods in your shopping cart, which the server then retrieves.

Additionally, David has discovered a CSRF vulnerability when changing a password and created some malicious HTML code.

<html>
  <body>
    <form action="vulnerable.com" method="POST">
      <input type="hidden" name="password" value="attacker" />
      <input type="hidden" name="password&#95;confirmation" value="attacker" />
      <input type="submit" value="Submit request" />
    </form>
  <script>
   document.addEventListener('DOMContentLoaded', function(event) {
    document.createElement('form').submit.call(document.getElementById('myForm'));
    });
  </script>
  </body>
</html>

Following that, David sent Bob his malicious code embedded on a trust.com.in host.

He can reset his password and we can take control of his account if he hits that link.

Bob's account is essentially compromised since reacted.com processes the request because Bob has authenticated and changes the password to "hacked."

This situation emphasizes how crucial it is to put in place appropriate security measures, like CSRF protection mechanisms, in order to thwart assaults of this nature. Adding anti-CSRF tokens or employing strategies like same-site cookies or double-submitted cookies to authenticate requests and make sure they came from the correct user's browser are common ways to prevent cross-site request fraud (CSRF).

You now have a clear understanding of CSRF.

Why is it not relevant during login/logout and out of scope?

This is due to the fact that the simple login/logout process won't have any significant effects and won't affect the bug. Assume the following scenario: you are managing a business and frequently encounter high-severity vulnerabilities such as XSS, SQL, etc. Thus, you will either fix that high severity or have no effect here.

Indeed, extreme severity is correct! Thus, act like a hacker and search for a big one!

And give the hacking community great pride by winning a big one! You're capable of it!

Let's hunt for CSRF!

  1. **Look for the action endpoint for state changes: **All that a state change action does is modify or change user data.

For instance, changing your password, deleting your account, and sending an email

  1. Lack of CSRF Protection: Determine whether a CSRF token is accessible. If so, we will use certain strategies to get around it, but by no means is it susceptible to CSRF (Same-site protection is also present occasionally).
  2. Verify the Vulnerability: Verify the vulnerability by creating an HTML form or by creating a CSRF HTML form using Burpsuite Pro.

Even while certain websites don't offer CSRF tokens, we can still use refer tokens to go around this and keep them safe.

Lab: Undefended CSRF vulnerability There is no defense against the CSRF vulnerability in this lab.

1. Initially, register or log in to that program.

You can use the following credentials to log into your account: wiener:peter

2. Locate the action endpoint for state changes:

It includes changing a password, email, address, canceling an account, and sending a message.

Any high-severity action endpoint that causes a significant change for the user can be selected, as the aforementioned endpoints serve as an example.

This is the email update endpoint where you can modify the mail

3. Lack of CSRF Protection: Use burpsuite to check for a lack of CSRF protection.

First, enter any email address, such as attacker@gmail.com. Then, capture that request using Burp and see if the content or the cookie contains a CSRF token.

[csrf_token = “TR7chhrmpGEmtjkBDwfYF6ohkfJLUow2”] is how it appears.

Additionally, go over the header X-CSRF: TR7chhrmpGEmtjkBDwfYF6ohkfJLUow2.

Thus, the CSRF token is absent.

3. In order to validate this vulnerability, draft the HTML form.

It would be simple to generate the CSRF POC. You can generate via Burp Suite Professional. However, if you don't have it, you can use the following steps 🤓

  1. Go to https://security.love/CSRF-PoC-Genorator/
  2. In the "URI" field, insert the URL that is vulnerable to CSRF. In this case, would be https://instance.web-security-academy.net/my-account/change-email
  3. In the "Data" field, insert the parameters required to perform the vulnerable request. In this case, would be email=attacker%40gmail.com
  4. Click the "Download CSRF PoC!" button

5. A csrfPoc.html field, should be download on your system. This is the exploit. Just run in the browser and click the button

6. You should be redirected to the vulnerable page. Voila! The victim's has changed to attacker's email. CSRF exploited!

Beginners Tip: Avoid the CSRF flaw in Chrome, use Firefox and pay attention to every state-changing queries.

Happy hunting!

Author: Ayush khatkar is a cybersecurity researcher, technical writer and an enthusiastic pen-tester at Asecurity. Contact here.

#bugbounty #infosec #cybersecurity