Basic Cross Site Request Forgery


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
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthjDlDFjwfiqAQFWIE

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:

Burp - Generate CSRF PoC

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

Written by Shain Lakin on 15 March 2021