Setting httpOnly on XSRF cookies

[Shane Spencer]

This seems like a very optional, but increasingly secure, requirement to help keep form submission in the context of the HTML form rather than allowing programmatic access to submit forms.

I understand browser support for this is rather lax, however a majority of the popular browsers support this cookie flag just fine.

I can submit a patch.  Anybody feel like this would inadvertently mess with a lot of existing deployments by causing XSRF failures where ajax requests would have succeeded after gleaning the token?

- Shane

[Ben Darnell]

Doesn't this pretty much break all uses of ajax POSTs?  tornado/demos/chat, for one, reads the cookie from javascript to make its requests.  And while you can pass the xsrf token to javascript in other ways than leaving the cookie accessible to scripts, you still have to get the cookie to javascript (on your own site) in some way so its requests can pass the xsrf test.  

I don't think it makes sense to set the httpOnly flag for the _xsrf cookie, although the 'secure' flag might make sense.  I set this one on all my https-only sites.  I'm not sure if we can set it by default, though.  It's easy enough to do something like this in your BaseHandler:

  def set_cookie(self, *args, **kwargs):

    kwargs.setdefault('secure', True)

    super(BaseHandler, self).set_cookie(*args, **kwargs)

-Ben

 

- Shane

--
You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shane Spencer]

Right.  When you end up dealing with AJAX on many platforms you end up either not using CSRF since it's easily defeated or using CSRF for forms and omitting it for REST calls.  It's a no fun situation.  I'm hoping to simply introduce a permit/deny or deny/permit toggle for this sort of thing when it comes to setting httpOnly.  I agree that secure is nice.  It definitely helps remind people that they need to make sure their xheaders are properly set via their frontend systems.

I'll probably just end up overriding set_cookie like you mention and tacking on a few bits for specific ones.

[Ben Darnell]

On Tue, Mar 25, 2014 at 10:44 PM, Shane Spencer <sh...@bogomip.com> wrote:

Right.  When you end up dealing with AJAX on many platforms you end up either not using CSRF since it's easily defeated or using CSRF for forms and omitting it for REST calls.  

Don't do this - you need CSRF protection as long as you're using cookie-based auth.  It's admittedly one of the more subtle security precautions to get right, but done properly it's reliable.

-Ben