Basic Cross Site Request Forgery

CSRF

Cross-site request forgery occurs when then following conditions exist:

The application contains an action that an attacker would wish to exploit. This could be anything from modifying permissions for other users (a privileged action) or a user specific action such as changing a users password or contact information such as email address etc.

The application issues HTTP requests to perform the action and relies on session cookies to identify the user. There cannot be another mechanism in place to validate the users identity or requests.

The request that induces an action does not include any parameters that an attacker cannot obtain the value of.

Example Request:

POST /me/email/update HTTP/1.1
Host: vuln-csrf.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthjDlDFjwfiqAQFWIE

email=user@vuln-csrf.com

To induce a desired action an attacker can use Burp Suite’s Generate CSRF Poc to generate a web page that the attacker can then host. When the victim browses to the attackers hosted page the request is sent and the desired action is induced. This occurs as the victims browser automatically includes the session cookie within the request (SameSite Cookies will mitigate this if set).

Generating a Poc using Burp Suite Pro:

Basic CSRF walkthrough:

Mitigating CSRF attacks

The most common mitigation against CRSF attacks is to include a CSRF token within requests that induce an action. SameSite cookie can also be used to prevent CSRF attacks.

Delivering CSRF attacks

The delivery mechanism can be anything that induces a victim to browse to the attackers site. This could be via social engineering, phishing, XSS or embedding html into another web site.

How to test:

Manually audit the web application with Burp Suite and check session management. If the session management relies solely on client side values then the web application is vulnerable.

Identifying CSRF due to token misconfiguration

• Change the request method from POST : Some applications skip token validation when a GET request is used instead of POST.

• Remove the CSRF token entirely: Some applications skip validation if the CSRF token is missing.

• Check if CSRF token is tied to the users session and if not obtain a token and use that : Some applications use a global pool of tokens and accept any token issued from that pool. For this attack to work you need to create or access a user account, intercept the action you want to induce and grab the associated CSRF token, drop the request and then use the captured token to craft the CSRF PoC targeting the victim.