1 DRAFT DOCUMENT - WORK IN PROGRESS

DRAFT DOCUMENT - WORK IN PROGRESS

Description

In short, CSRF abuses the trust relationship between browser and server. This means that anything that a server uses in order to establish trust with a browser (e.g., cookies, but also HTTP/Windows Authentication) is exactly what allows CSRF to take place - but this only the first piece for a successful CSRF attack.

The second piece is a web form or request which contains parameters predictable enough that an attacker could craft his own malicious form/request which, in turn, would be successfully accepted by the target service. Then, usually through social engineering or XSS, the victim would trigger that malicious form/request submission while authenticated to the legitimate service. This is where the browser/server trust is exploited.

In order to prevent CSRF in ASP.NET, anti-forgery tokens (also known as request verification tokens) must be utilized.

These tokens are simply randomly-generated values included in any form/request that warrants protection. Note that, ideally, this value should be unique for every actual form/request, not just for every type of form/request. This guarantees that every form/request is unique and, therefore, protected from CSRF.

Mitigation Examples

Please note that the following examples may not entail a complete anti-CSRF solution for any given Web application. Specific requirements may call for adjustments and/or combinations of different strategies.

Solutions NOT considered secure

- Assuming that SSL/TLS will thwart CSRF attacks just because the cookie is marked "Secure" and/or "HTTPOnly". The problem lies in the trust between legitimate browser and server. Therefore, the browser will just send its current cookies when the forged request is triggered. The attacker never has to touch any cookies.

- Referer header verification as the only protection. This can be easily manipulated.

- Cookie double-submission when the cookie utilized is the session cookie. This exposes the session cookie to JavaScript. Always mark the session cookie "HTTPOnly" so that it cannot be accessed with JavaScript.

- Any CSRF protection is null and void given the presence of XSS, for several reasons. The main and obvious reason is that, through XSS, the attacker can hijack the session and spoof the user, not even having to worry about performing CSRF.

Anti-CSRF Token

ASP.NET has the capability to generate anti-CSRF security tokens for consumption by your application, as such:

1) Authenticated user (has session which is managed by the framework) requests a page which contains form(s) that changes the server state (e.g., user options, account transfer, file upload, admin functions, etc.)

2) Generate the security token (or grab it from the session state) and send the token as a session cookie (again, managed in the session state, unique per session) as well as within a hidden value in each form.

3) Once the user submits the form, validate the token stored in the session state against the token included in the submitted form value. On failure, disregard form.

Effectively, this is the cookie double-submission approach done right, since the security token is submitted both as a cookie (managed in the framework session state) and within a hidden form value at the same time.

For implementation details, see:
CSRF Prevention (official ASP.NET blog)
Preventing CSRF Attacks (official ASP.NET blog)

You may consider making a new security token for every new request, rather than session:
Why refresh CSRF token per form request?