How to protect against login CSRF?

Question

http://seclab.stanford.edu/websec/csrf/csrf.pdf points out that most CSRF protection mechanisms fail to protect login forms. As https://stackoverflow.com/a/15350123/14731 explains:

The vulnerability plays out like this:

1. The attacker creates a host account on the trusted domain
2. The attacker forges a login request in the victim's browser with this host account's credentials
3. The attacker tricks the victim into using the trusted site, where they may not notice they are logged in via the host account
4. The attacker now has access to any data or metadata the victim "created" (intentionally or unintentionally) while their browser was logged in with the host account

This attack has been successfully employed against Youtube.

The authors of the paper went on to propose the addition of an "Origin" header but ran into resistance by W3C members: http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0035.html

To date, only Chrome and Safari implements the "Origin" header. IE and Firefox do not and it's not clear whether they ever will.

With that in mind: what is the best way to protect against CSRF attacks on login forms?

UPDATE: I am looking for a RESTful solution, so ideally I want to avoid storing server-side state per user. This is especially true for non-authenticated users. If it's impossible then obviously I will give up on this requirement.

Answer 1

With anonymous cookies

If you are happy to generate secure tokens which are set as anonymous users' cookies, but not to store them server side then you could simply double submit cookies.

e.g. Legitimate user:

1. Anon user navigates to the login page, receives cookie which is sent to the browser.
2. Anon user logs in and the browser sends the cookie as a header and as a hidden form value.
3. User now logged in.

This cannot be abused by the attacker as the following will now happen:

1. The attacker creates a host account on the trusted domain
2. The attacker forges a login request in the victim's browser with this host account's credentials However, the attacker does not have access to the victim's cookie value and cannot forge it as the CSRF token in the request body. The attack fails.

Even if your site is only accessible over HTTPS and you correctly set the Secure Flag, care must be taken with this approach as an attacker could potentially MiTM any connection from the victim to any HTTP website (if the attacker is suitably placed of course), redirect them to your domain over HTTP, which is also MiTM'd and then set the required cookie value. This would be a Session Fixation attack. To guard against this you could output the cookie value to the header and the hidden form field every time this (login) page is loaded (over HTTPS) rather than reuse any already set cookie value. This is because although a browser can set the Secure Flag, it will still send cookies without the Secure Flag over a HTTPS connection, and the server will not be able to tell whether the Secure Flag was set. (Cookie attributes such as the Secure Flag are only visible when the cookie is set, not when it is read. The only thing the server gets to see is the cookie name and value.) Implementing HSTS would be a good option for protection in supported browsers.

It is advisable to set X-Frame-Options to prevent a UI redress click jacking attack (otherwise the attacker could possibly use site functionality to pre fill their username and password awaiting the user to click and submit them along with the CSRF value).

Without anonymous cookies

If you do not want to set cookies for anonymous users (which then may suspect that they are being tracked server side) then the following approach may be used instead: A multi-stage login form.

The first stage is the usual username / password combination.

After the form is submitted, it redirects to another form. This form is protected by a special intermediary authentication token cookie and a CSRF token. The authentication here will only allow the second stage authentication to be submitted, but will not allow any other actions on the account (except possibly a full logout). This will enable the CSRF token to be associated and used by this user account only on this intermediary session.

Now it is only when this form is submitted, including the token cookie and CSRF hidden form value that the user is fully authenticated with the domain. Any attacker attempting a CSRF attack will not be able to retrieve the CSRF token and their full login attempt will fail.

The only drawback is that the user will have to manually click to complete login, which may be a clunky user experience. It is advisable to set X-Frame-Options to prevent this being used in combination with a UI redress click jacking attack. Any auto submission with JavaScript would be beneficial to the attacker and would cause their attack to possibly succeed, so at the moment I can only see a manual click by the user working.

It would now play out like this:

1. The attacker creates a host account on the trusted domain
2. The attacker forges a login request in the victim's browser with this host account's credentials but they cannot proceed past stage two to become fully authenticated
3. The attacker tricks the victim into using the trusted site - but as they are not fully authenticated, the site will act as though the user is unauthenticated

Answer 2

So a slightly niche requirement, but hey a valid CSRF. There's a couple of choices of how you can address this that spring to mind

• Standard anti-automation techniques like a CAPTCHA. Of course not the most user friendly of solutions but can help mitigate other attacks at the same time.
• Have a standard Anti-CSRF token which is tied to information provided by the client which is available pre-authentication. An obvious option would be to tie it to source IP address. That's not perfect (systems behind proxies would have the same address) but would reduce the risk quite a bit. Another option would be to tie the token to specific browser identities. If you look at Panopticlick you can see that browsers provide identifying information so it might be possible to create a fingerprint based on that and issue one Anti-CSRF token for each fingerprint which contacts the site. Again not perfect but makes the attack harder to execute.

Answer 3

I'd like to propose a variant of the Encrypted Token Pattern which works as follows: When a client requests an HTML page needing CSRF protection...

1. The server checks for the existence of a sessionId cookie. If it is missing, the server sets a new HttpOnly cookie containing a cryptographically-strong pseudorandom value. Note this value is not stored on the server but it still protects against login CSRF (an attacker cannot authenticate without passing through the login form).
2. If the user is logged out, return an HTML page that triggers authentication for unsafe operations. Go back to step 1.
3. If the user is logged in, the server encrypts [sessionId + nonce] using a secret key and embeds the value (which we shall call csrfToken) into the HTML file. It isn't important where csrfToken is embedded, so long as the Form or Javascript function making the request can access it. nonce is a cryptographically-strong pseudorandom value used to prevent brute-force attacks on the secret key, but is not used during the validation process.
4. Forms submit csrfToken using a hidden field of the same name. Javascript functions submit csrfToken using a custom request header named csrf-token.
5. The server decrypts csrfToken and compares its value to sessionId. If the two don’t match, the server returns 401 Unauthorized and triggers authentication.

Answer 4

You can apply any of the standard anti-CSRF techniques, be it the Synchronizer Token Pattern or Double Submit Cookies. The former is generally more secure, because cookies can be overwritten by subdomains.

You claimed that the Synchronizer Token Pattern only works after authentication, but this is not the case. An attacker does not have access to the token of a user, regardless of whether the user is authenticated or not.

Of course the attacker can visit the login page herself and obtain a valid anti-CSRF token. But this token only works for the attacker. If the victim makes a request, then the token is not accepted, because it's not present in the victim's session. In fact, the session will be entirely empty on the first request.