Comments on: CSRF, Crumbs, and Cookies. http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/ Tue, 16 Feb 2010 12:31:46 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Simon Willison http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29380 Simon Willison Fri, 03 Oct 2008 22:22:51 +0000 http://www.zwitserloot.com/?p=155#comment-29380 One thing that's worth considering is that it's easier to accidentally leak a CSRF crumb than it is to accidentally leak a session. Crumbs are used in forms, which means that if you accidentally include a crumb in a GET form it could end up in a URL - which might then leak to someone's referrer logs. If you are automatically adding crumbs to any forms on your site you might accidentally add the crumb to a form with an action pointing somewhere else, which is another way that the crumb could leak. OK, so neither of the above are hugely likely, but just in case it's nice to know that the crumb you are leaking is securely derived from your session ID rather than being identical to it. One thing that’s worth considering is that it’s easier to accidentally leak a CSRF crumb than it is to accidentally leak a session. Crumbs are used in forms, which means that if you accidentally include a crumb in a GET form it could end up in a URL – which might then leak to someone’s referrer logs. If you are automatically adding crumbs to any forms on your site you might accidentally add the crumb to a form with an action pointing somewhere else, which is another way that the crumb could leak.

OK, so neither of the above are hugely likely, but just in case it’s nice to know that the crumb you are leaking is securely derived from your session ID rather than being identical to it.

]]> By: rzwitserloot http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29332 rzwitserloot Fri, 03 Oct 2008 01:37:28 +0000 http://www.zwitserloot.com/?p=155#comment-29332 Good one, Mark. random+SHA256(random+sessionID) at the very least has a clear advantage over raw sessionIDs in the page proper. Tipit requires javascript at the moment so I don't need to send the session as the server; the javascript just fishes it out of the cookie. But, that's the exception and not the norm, so, yeah. definitely need to hash something. Good one, Mark. random+SHA256(random+sessionID) at the very least has a clear advantage over raw sessionIDs in the page proper.

Tipit requires javascript at the moment so I don’t need to send the session as the server; the javascript just fishes it out of the cookie. But, that’s the exception and not the norm, so, yeah. definitely need to hash something.

]]> By: cbetta http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29305 cbetta Thu, 02 Oct 2008 17:55:58 +0000 http://www.zwitserloot.com/?p=155#comment-29305 True. Quite a good point there. Still means anyone doing CSRF should always think of setting the cache-control headers properly to prevent CSRF problems. True. Quite a good point there. Still means anyone doing CSRF should always think of setting the cache-control headers properly to prevent CSRF problems.

]]> By: Mark Ng http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29303 Mark Ng Thu, 02 Oct 2008 17:52:41 +0000 http://www.zwitserloot.com/?p=155#comment-29303 @cbetta also, of course, you'd be restricted to actions within that form, rather than actions across the whole site. @cbetta also, of course, you’d be restricted to actions within that form, rather than actions across the whole site.

]]> By: Mark Ng http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29302 Mark Ng Thu, 02 Oct 2008 17:51:04 +0000 http://www.zwitserloot.com/?p=155#comment-29302 @cbetta sure, but stealing a CSRF token in this context means that you have to steal the CSRF token from the proxy, identify the user that CSRF token belongs to (difficult, unless you know the proxy is only being used by a couple of people) and then persuade that user to visit a URL with your CSRF attack script in it. Much less easy than just stealing someones session ID and not having to know which user it is in advance. @cbetta sure, but stealing a CSRF token in this context means that you have to steal the CSRF token from the proxy, identify the user that CSRF token belongs to (difficult, unless you know the proxy is only being used by a couple of people) and then persuade that user to visit a URL with your CSRF attack script in it.

Much less easy than just stealing someones session ID and not having to know which user it is in advance.

]]> By: cbetta http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29299 cbetta Thu, 02 Oct 2008 17:46:00 +0000 http://www.zwitserloot.com/?p=155#comment-29299 @markng that same issue arrises for normal CSRF tokens, right? although those are just tokens, not entire session IDs @markng that same issue arrises for normal CSRF tokens, right? although those are just tokens, not entire session IDs

]]> By: Mark Ng http://zwitserloot.com/2008/10/02/csrf-crumbs-and-cookies/comment-page-1/#comment-29298 Mark Ng Thu, 02 Oct 2008 17:38:14 +0000 http://www.zwitserloot.com/?p=155#comment-29298 My immediate thought is that you'd have to be careful with cache-control headers if you were going to send the session ID unhashed in the page. A caching proxy won't send you someone elses cookies, but it will send you someone elses page if it hasn't been told it's private. This would mean that someone could get your session ID by using the same proxy as you. My immediate thought is that you’d have to be careful with cache-control headers if you were going to send the session ID unhashed in the page.

A caching proxy won’t send you someone elses cookies, but it will send you someone elses page if it hasn’t been told it’s private. This would mean that someone could get your session ID by using the same proxy as you.

]]>