Full Disclosure mailing list archives
Re: [WEB SECURITY] Preventing Cross-site Request Forgeries
From: Stephen de Vries <stephen () twisteddelight org>
Date: Mon, 2 Apr 2007 11:01:03 +0700
Interesting post pdp, and implementing such a solution could be a lot easier than coding the nonce generation yourself. Some existing web frameworks already provide a similar feature by creating another layer of state management on top of the HTTP session. One of the cleanest examples is JBoss Seam (http:// www.jboss.com/products/seam) which defines a "conversation" state in addition to the usual session state. Spring webflow does something similar (http://www.springframework.org/webflow) for pageflow, and there are probably more web frameworks that have implemented similar solutions for workflow and pageflow. None of these solutions were born out of a need for more security. Rather, developers need something more granular than the session state to keep track of user actions and they need to more easily control page flow within an app. If you try out the Seam demo's you'll see that the session management (or conversation management) is more robust than a typical web app - because the app defines distinct conversations which require another ID (similar to your nonce values) for requests that are part of a conversation. E.g. when you start performing a checkout operation, a new conversation ID is generated and used for all subsequent requests until that conversation has been completed. As far as CSRF is concerned, some implementation of these solutions are not bullet proof. For example, in Seam, the conversation ID value is a simple numeric value that is global across all users. So an attacker could create his own conversation, read the ID, and predict the ID which will be used for subsequent conversations by other users. Fixing this is simply a matter of generating random ID's rather than sequential ones. Spring webflow on the other hand appears to generate random flow Ids, but by default the ID seems to be passed as a URL parameter rather than a form value, so disclosure through referer is possible. But both of these limitations are implementation problems, which can be fixed quite easily, rather than flaws in the overall design. Additional levels of state management like these allow developers to build applications which support workflow and pageflow more easily and naturally than with vanilla HTTP session management. And the fact that they could potentially be used to mitigate the risk of CRSF is an added bonus. So we may be lucky in this case, that an industry trend towards pageflow and workflow based web applications overlaps with the need for CSRF protection. Two birds with one stone. regards, Stephen On 30 Mar 2007, at 17:16, pdp (architect) wrote:
http://www.gnucitizen.org/blog/preventing-csrf I briefly covered how simple it is to prevent CSRF attacks. Hope that you find it useful. -- pdp (architect) | petko d. petkov http://www.gnucitizen.org ---------------------------------------------------------------------- ------ Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
-- Stephen de Vries Corsaire Ltd E-mail: stephen () corsaire com Tel: +44 1483 226014 Fax: +44 1483 226068 Web: http://www.corsaire.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: [WEB SECURITY] Preventing Cross-site Request Forgeries Stephen de Vries (Apr 02)