Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Say I've got that web application that has a CSRF protection according to the Synchronizer Token Pattern. The server expects a valid CSRF token in each POST request when the user is authenticated. Now imagine the following scenario:

  1. The user opens a browser tab (tab anonymous) and starts some AJAX functionality that periodically reads from the server (e.g. a timestamp). The user is not authenticated in this tab.

  2. The user opens a new browser tab (tab authenticated) and performs a login there. If he now loads the AJAX framework, the CSRF token gets written into the source code of the AJAX framework by server-side includes and gets stored in the variable token.

  3. If the next automatic poll is done from tab anonymous, the session cookie gets submitted indicating a logged in user but this tab never received a CSRF token since the AJAX framework was loaded before performing the login on tab authenticated.
    This will result in an error thrown by the server because it received a valid session token without CSRF protection token.

How do I overcome this?


Edit:
Things get even worse if the user

  • does a login on tab 1 (user1)
  • opens tab 2
  • does a logout on tab 2
  • performs a new login on tab 2 (different user, user2)

In that case, the first tab provides the formerly valid CSRF token of user1 but the submitted session cookie belongs to user2 logged in on tab 2. This must lead to an error issued by the CSRF protection (by the way, in terms of HTTP error codes: what to use? 403 looks as if it could be used but I'm unsure).

Feeling now like the whole CSRF thing could be solved very nice in theory but could use some thinking in times of AJAX.

Is there any canonical solution for the issue described above? Or do users simply accept that they have to reload a page due to security-thingies-don't-match stuff?

share|improve this question
    
@downvoter: could you please enlighten me with the reason for downvote? –  eckes Nov 12 '12 at 12:21
add comment

2 Answers

up vote 3 down vote accepted

You could have a flag in your anonymous requests to let them know they are always treated as anonymous, despite the presence of the authentication cookie.

e.g. { "Anon" : "true" }

This will always cause the public results of the request to be returned and no auth cookie or CSRF request token will be considered in the logic.

share|improve this answer
    
Unless you were careful, wouldn't this just introduce a client-side way of disabling the check? You would have to mark some server side end points to explicitly allow the 'disable' behaviour. –  JT. Dec 17 '13 at 1:20
    
Yes, this would have to be implemented properly. The Anon flag would need to cause the request to effectively be treated as unauthenticated. –  SilverlightFox Dec 17 '13 at 10:05
add comment

As far as I've seen, all browsers tabs and open windows to the same website share the same cookie data. A cookie set in one tab is visible in all other tabs.

With regards to CSRF protection in a HTTP POST action there is a value embedded in the HTML output. You could include a value in HTML that gets POSTed back that can tell the back end to ignore any authentication token that may be present.

You would have to add this HTML token to each and every webpage that uses CSRF protection, and update every Javascript POST to send this value when dealing with service requests.

It's a bit hairy, depending on how complex your site is, but it can be done.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.