CSRF Vulnerability Explained | OWASP TOP 10 2021 : Broken Access Control

Introduction

The CSRF or Cross Site Request Forgery is a web vulnerability, where an attacker tricks the victim’s browser to send forged requests to a website which performs certain actions on behalf of the logged in user or the victim. The web server processing the request executes the desired actions of the request, as it looks similar to any normal requests generated by the users browser.

However, browsers don’t allow reading across sites; for example, this website can’t read content on pages you may have open in other tabs. However, form submissions across sites or domains are allowed. It’s through that security loophole that the CSRF attack is possible in the first place. At the heart of the CSRF vulnerability is a “confused deputy problem” which happens when a web browser isn’t able to properly validate a web app user that is logged in.

The CSRF attacks are usually conducted by using malicious social engineering tricks and techniques, such as an email or link that tricks the victim into sending a forged request to a server. As the victim is authenticated by their vulnerable target application at the time of attack, then its impossible to distinguish a legitimate request from a forged one.

The targets of CSRF attacks include web applications like social media, in-browser email clients, online banking and web interfaces for network devices. The CSRF vulnerabilities can vary a lot in severity, for example an attacker could change the settings or posts something on behalf of victim, but in critical conditions it could also lead to password change, account takeover, and so on.

How CSRF Attacks Works

In CSRF attack the forged web requests are sent form a malicious site that the victim visits to the target site or web application that the attacker believes the victim is logged in or validated against. At here the malicious site is controlled by the attacker. The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site. Now here the vulnerability lies in the affected web application/target site, not the victim’s browser or the site hosting the CSRF exploit.

For example lets say there is a banking web application by which we can transfer funds to different accounts, where the user needs to be log-in in order to transfer funds.

Steps of CSRF Attack

  1. First the user/victim will log into banking application to transfer funds.
  2. Then user/victim Then visits the attackers controlled malicious site while he still logged in to the banking application.
  3. At this point the attacker believing that the victim is logged in into his bank account. Now the attacker embedded some javascript code in his malicious website to send the forged request to the banking application on the behalf of victim. The forged request might contains the fund transfer requests to the attackers bank account from victim account.
  4. Now the banking application automatically validates the transaction without re-authenticating, because the victim is logged-in and the request appears to be coming from the user.

Example of CSRF Attack

Sample php code used in below example can be download from here Link here. For example lets assume victim is logged into the below online banking page where he/she can transfer money from our account.

CSRF Example

When victim put the amount and account number and click on submit button, it will process our transaction request.

CSRF Example
CSRF Example

Now there is also a malicious page called csrf.php, which send the forged request to bank application with altered amount and account number. The code for csrf.php is :

<html>
  <body onload="document.getElementById('xsrf').submit();">
    <form id="xsrf" method="GET" action="transfer.php">
      <input name="amount" type="hidden" value="1000">
      <input name="AcNo" type="hidden" value="999999999">
      <input name="action" type="hidden" value="Change">
    </form>
  </body>
</html>

Now as we can see the above form is auto-submitting from, and when we open that page then it will immediately send the request to transfer.php file.

CSRF Example

The above example is simple demonstration of csrf attack, but not an accurate one, because there is no sign-in mechanism. To test the above code put the above code on root directory in your web server (for example xampp) and open the bank.php in your browser.

Prevention from CSRF Attacks

The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append CSRF tokens to each request and associate them with the user’s session.

A CSRF token is a unique, unpredictable secret value generated by a server-side application, and sent to the client for inclusion in subsequent HTTP requests issued by the client. After the token is issued, when the client makes a request, the server checks to see if the request contains the expected token, and rejects it if the token is missing or invalid. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user. Some of the other advanced methods are :

  • Use the same site attribute cookie. Read here for more details : Link.
  • User interaction based csrf defense, for example captcha or OTP based system to ensure that it is the user and not any bot or an attacker on some important functions like financial transaction, account deletion or modification etc.

References :

  • https://en.wikipedia.org/wiki/Confused_deputy_problem
  • https://www.neuralegion.com/blog/cross-site-request-forgery-csrf/

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.