10

I'm building a CSRF prevention method in our application framework. I use, inter alia, the OWASP site.

We have chosen for the "Double Submit Cookies" prevention meassure, described at the OWASP CSRF cheat sheet

The cheat sheet states:

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value...

It sound like an user must log in first, before generating the CSRF token (aka "(cryptographically strong) pseudorandom value").

But how do I protect the forms who are accessible without authentication? Think about "forgotten password" and the login form.

I think the text should be "When a user enters a site, the site should generate a (cryptographically strong) pseudorandom value..."

This is also easier to implement, as I did on the following way:

  • Application retrieves GET request: generate CSRF (session) cookie (if cookie isn't already in request)
  • (else) Application retrieves non-GET (POST, PUT etc) request: validate CSRF cookie with CSRF token in request.

Am I missing a important aspect here?

Julian
  • 536
  • 7
  • 19

1 Answers1

4

Typically, you do not protect forms that are accessible without authentication. The purpose of a CSRF attack is generally for an attacker to manipulate an authenticated user to perform an action on the site at with the attacker's data and the victim user's authenticated session. Forms that do not require authentication generally aren't vulnerable to being manipulated in this way.

So, CSRF mitigations are typcially framed using language that assumes/requires the user to be authenticated in order for the vulnerability to exist. Lumping unauthenticated forms in changes the threat model to one that may be valid for a given interaction, but is non-standard.

Your approach

Form a security perspective, your approach looks fine. It eliminates the ability to generate a POST or PUT without a preceding GET, but for a browser-based interface that shouldn't generally be an issue, and for this specific threat model, is exactly what you need.

Xander
  • 35,796
  • 27
  • 116
  • 144
  • 1
    Good point, but as far as I understood, it's good practice to protect the login form with a CSRF token (login CSRF): http://security.stackexchange.com/a/2126/54986 – Julian Dec 15 '14 at 21:27
  • @Julian That is probably the most common exception, but it's still a special case, separate from the standard CSRF threat model. If fact, you'll find that many applications don't consider it a valid threat at all. For your application, it may or may not be, you're best suited to determine that. – Xander Dec 15 '14 at 21:38
  • Well I like to write generic code, especially when it concerns safety, then writing some code which is based on exceptions. – Julian Dec 15 '14 at 21:47
  • @Julian It doesn't really have anything to do with code specifically, but the model. This is why the directive is written as it. It is correct for the general case. Broadening the language would be incorrect, as it would bring into scope components that are in fact out of scope. – Xander Dec 15 '14 at 21:50
  • @Julian Added a bit, to address your specific approach. – Xander Dec 15 '14 at 22:17
  • Anti CSRF token are used to determine the origine of the request before submitting or modifying data in a database for example. Therefor it is not required to protect a login mechanism. Rather put some effort in anti scripting mechanism(s). – Jeroen Dec 16 '14 at 06:04