Absence of Anti-CSRF Tokens

The absence of Anti-CSRF tokens may lead to a Cross-Site Request Forgery attack that can result in executing a specific application action as another logged in user, e.g. steal their account by changing their email and password or silently adding a new admin user account when executed from the administrator account.

The attacker may copy one of your web application forms, e.g. email/password change form.

The webpage will contain a form with the exact set of fields as the original application but with input values already provided and the submit button replaced with a Javascript code causing auto-submission. When the page is accessed the form will be immediately submitted and page contents replaced with a valid content or a redirect to your original application.

One of your application users who is already logged in can be then tricked to navigate to such malicious page e.g. by clicking a link in a phishing email, and the pre-populated form content will be submitted to your application like it would be submitted by your user.

This problem can be resolved by adding a temporarily valid token to any form submission in your application, e.g. as a hidden field:

<input type="hidden" name="csrf" value="Fijd93djskDsdis9wijdSD938jISdj93jdISdj9s" />

so that only form submissions containing a valid token value will be accepted by your application. The attacker building a phishing page cloning your form won’t be able to come up with a valid token and mimic a valid submission with malicious data.

You should follow these guidelines when generating and then accepting a form submission token:

1. Token value should not be predictable, e.g. could be generated with a trustworthy and properly configured random generator.
2. Tokens should expire after a short period of time, so they cannot be reused.
3. You should not use local timestamps as tokens without server-side encryption.
4. Do not send anti-CSRF tokens in HTTP GET requests, so they do not leak in URL or the request header.

One of the options that do not require any persistent token storage in your application would be to create a token from the form name, user name and the current timestamp, then encrypt it symmetrically with a key known only to your server side application.

When accepting a form submission you would then decrypt the received token, extract the form name, user name and the timestamp, and compare the latter with the current time making sure it was not generated too long ago.

We report the actual location of the web form in your web application that does not seem to contain an additional attribute with an anti-CSRF token using a predefined list of the most popular anti-CSRF field names.

The identified forms should be manually reviewed to confirm that there is no Anti-CSRF protection in place and fixed where needed.