by peter

Share

Cross-site request forgery CSRF Explained

Risk

Risk Rating: HIGH
Likelihood: 3/5
Impact: 5/5

Causes

  • Lack of Web Application firewall
  • Lack of monitoring
  • Poor coding

Cross-site request forgery CSRF Overview

Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated. CSRF attacks exploit the trust a Web application has in an authenticated user. (Conversely, cross-site scripting (XSS) attacks exploit the trust a user has in a particular Web application). A CSRF attack exploits a vulnerability in a Web application if it cannot differentiate between a request generated by an individual user and a request generated by a user without their consent.

What you need to know about Cross-Site Request Forgery

To defeat a Cross-Site Request Forgery attack, applications need a way to determine if the HTTP request is legitimately generated via the application’s user interface. The best way to achieve this is through a CSRF token. A CSRF token is a secure random token (e.g., synchronizer token or challenge token) that is used to prevent CSRF attacks. The token needs to be unique per user session and should be of large random value to make it difficult to guess.

A Cross-Site Request Forgery secure application assigns a unique CSRF token for every user session. These tokens are inserted within hidden parameters of HTML forms related to critical server-side operations. They are then sent to client browsers.

It is the application team’s responsibility to identify which server-side operations are sensitive in nature. The CSRF tokens must be a part of the HTML form—not stored in session cookies. The easiest way to add a non-predictable parameter is to use a secure hash function (e.g., SHA-2) to hash the user’s session ID. To ensure randomness, the tokens must be generated by a cryptographically secure random number generator.

Whenever a user invokes these critical operations, a request generated by the browser must include the associated CSRF token. This will be used by the application server to verify the legitimacy of the end-user request. The application server rejects the request if the CSRF token fails to match the test.

You can test for and detect Cross-Site Request Forgery vulnerabilities through good quality web application penetration testing.

How Cross-Site Request Forgery (CSRF) attacks happens

An attacker’s aim for carrying out a Cross-Site Request Forgery attack is to force the user to submit a state-changing request. Examples include:

  • Submitting or deleting a record.
  • Submitting a transaction.
  • Purchasing a product.
  • Changing a password.
  • Sending a message.

Social engineering platforms are often used by attackers to launch a Cross-Site Request Forgery attack. This tricks the victim into clicking a URL that contains a maliciously crafted, unauthorized request for a particular Web application. The user’s browser then sends this maliciously crafted request to a targeted Web application. The request also includes any credentials related to the particular website (e.g., user session cookies). If the user is in an active session with a targeted Web application, the application treats this new request as an authorized request submitted by the user. Thus, the attacker succeeds in exploiting the Web application’s CSRF vulnerability.

A Cross-Site Request Forgery attack targets Web applications failing to differentiate between valid requests and forged requests controlled by attacker. There are many ways for an attacker to try and exploit the CSRF vulnerability.

To give you an example, let’s say that Alice has an online esports account on esports.gi. She regularly visits this site to conduct transactions with her friend Jane. Alice is unaware that esports.gi is vulnerable to CSRF attacks. Meanwhile, an attacker aims to transfer £5,000 from Alice’s account by exploiting this vulnerability. To successfully launch this attack:

  1. The attacker must build an exploit URL.
  2. The attacker must also trick Alice into clicking the exploit URL.
  3. Alice needs to have an active session with esports.gi.

Let’s say that the online egaming application is built using the GET method to submit a transfer request. As such, Alice’s request to transfer £50 to Jane (with account number 31337) might look like this:

GET https://esports.gi/acc/transfer?amount=50&accountNumber=31337 HTTP/1.1

Aligning with the first requirement to successfully launch a CSRF attack, an attacker must craft a malicious URL to transfer £5,000 to the account 1234567:

https://esports.gi/acc/transfer?amount=5000&accountNumber=1234567

Using various social engineering attack methods, an attacker can trick Alice into loading the malicious URL. This can be achieved in various ways. For instance, including malicious HTML image elements onto forms, placing a malicious URL on pages that are often accessed by users while logged into the application, or by sending a malicious URL through email.

Consider the scenario that includes an image tag in an attacker-crafted email to Alice . Upon receiving it, Alice’s browser application opens this URL automatically—without human intervention. As a result, without Alice’s permission, a malicious request is sent to the online banking application. If Alice has an active session with egaming.gi, the application would treat this as an authorized amount transfer request coming from Bob. It would then transfer the amount to the account specified by an attacker.

There are some limitations. To carry out a successful CSRF attack, consider the following:

  • The success of a Cross-Site Request Forgery attack depends on a user’s session with a vulnerable application. The attack will only be successful if the user is in an active session with the vulnerable application.
  • An attacker must find a valid URL to maliciously craft. The URL needs to have a state-changing effect on the target application.
  • An attacker also needs to find the right values for the URL parameters. Otherwise, the target application might reject the malicious request.

Attack Sources

Attacks can come from anywhere. There are s small number of tools available to automate scanning for Cross-Site Request Forgery vulnerabilities, such as Bolt. Consider restricting access to your applications to specific countries that you do business with.