On Mar 9, 2011, at 11:24 AM, Stephen Lacy wrote: > CSRF protection is a fairly complex topic, and Pyramid's brief textual > description in the docs above really glosses over many of the important > aspects of how to handle CSRF protection.
It's messy, but I didn't think it was too bad. In short, evil hackers can drop iframe's that do POST's into your page. Since the iframe/etc is in the right domain for the POST, your cookies are used. Thus someone could cause you to update your password, change your bank account info, etc. if they happen to get you to visit their page that drops the iframe and you happen to be logged into the other site they want you to POST to. To prevent this, we take advantage of the fact that thus far (who knows about the future), an attacker making an exploit page *could* make a page that does a GET to the form, but due to browser restrictions cannot actually read the contents of the other page, nor fill out the form and make it POST. So we include a hidden token field in the form, that must be present on the POST as well for it to succeed. We store a copy of the token in a users session so that we have something to check the form POST against to ensure the token's match up. > The key question you need to think about when implementing CSRF checking is > "when should I generate a new CSRF token?". You can't generate a new CSRF > token with every request, because of things like AJAX and loading of other > resources (images, CSS, js) that are coming through your server. Remember > that your server is going to be hit several times for each "page." That's true, but whether every AJAX request needs to do a POST requiring the CSRF token.... is questionable. But anyways, assuming you have no XSS holes allowing someone to possibly steal your cookies... :) I see no reason a CSRF token couldn't be valid for 5-25 minutes or more. Barring an XSS hole, the attacker would have no way to get at the cookie contents nor any way to figure out what the token is that must be included on every POST, so the existing token is still secure for the duration of a users visit. A shorter valid token period would be good solely to deal with the possibility that your site might also have another hole allowing someone to steal a cookie (and thus forge the entire GET/POST as the other user). The Pyramid docs mainly show how to issue a new csrf token, and how to check it, the basics needed for CSRF protection. Rotating them every time its checked seems a bit like overkill, especially if you do assume the AJAX situation where multiple things might hit all at once, in which case the first check would invalidate the others. Django's system was flawed in that it assumed when a specific HTTP header was present, the CSRF token check should be skipped entirely. I never understood why they had that, Rails and other frameworks also did the HTTP header check and skipped their respective CSRF systems so maybe they just copied it assuming someone else was sure the header couldn't be forged. I generally don't trust HTTP headers, so I never included such a skip or recommendation to ever skip checking the CSRF token (Django and the others have since fixed this security bug). So I guess I would consider a CSRF token to be usable and valid from the users login, to the users logout on your website. If there was a way to steal cookies from your users, the CSRF token wouldn't matter since the attacker could use the stolen cookie to do a GET/POST with a new CSRF token as the other user. Thus any additional rotation of the CSRF token seems a bit overkill and more prone to cause situations where a user might hit the back button and try to re-submit a form causing them to see a CSRF error and think they're being hacked or something when they aren't. Cheers, Ben -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
