Re: [Full-disclosure] [WEB SECURITY] Preventing Cross-site Request Forgeries
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: [EMAIL PROTECTED] 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/
Re: [Full-disclosure] [WEB SECURITY] Preventing Cross-site Request Forgeries [ASP.NET crowd]
Nice article. For the ASP.NET crowd out there, the will be even more simple, one line of code. Set the ViewStateUserKey property in your base class or page and the unique token protections (similar to CSRF_Guard) will be provided for you. http://msdn2.microsoft.com/en-us/library/system.web.ui.page.viewstateuserkey .aspx This protection mechanism has been available for many years, since the Framework 1.1 -Original Message- From: pdp (architect) [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 3:16 AM To: full-disclosure@lists.grok.org.uk; WASC Forum; webappsec @OWASP Subject: [WEB SECURITY] Preventing Cross-site Request Forgeries 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] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Preventing Cross-site Request Forgeries [ASP.NET crowd]
The EnableEventValidation page directive (enabled by default since .Net 2.0) applies a nonce value for form validation and is also a strong control to prevent CSRF attacks. Michael Sutton Security Evangelist SPI Dynamics http://portal.spidynamics.com/blogs/msutton -Original Message- From: Chris Weber [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 6:12 PM To: 'pdp (architect)'; full-disclosure@lists.grok.org.uk; 'WASC Forum'; 'webappsec @OWASP' Subject: RE: [WEB SECURITY] Preventing Cross-site Request Forgeries [ASP.NET crowd] Nice article. For the ASP.NET crowd out there, the will be even more simple, one line of code. Set the ViewStateUserKey property in your base class or page and the unique token protections (similar to CSRF_Guard) will be provided for you. http://msdn2.microsoft.com/en- us/library/system.web.ui.page.viewstateuserkey .aspx This protection mechanism has been available for many years, since the Framework 1.1 -Original Message- From: pdp (architect) [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 3:16 AM To: full-disclosure@lists.grok.org.uk; WASC Forum; webappsec @OWASP Subject: [WEB SECURITY] Preventing Cross-site Request Forgeries 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] -- -- 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] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Preventing Cross-site Request Forgeries [ASP.NET crowd]
Actually that's not true. We should be clear that this is *not* the same thing as ViewStateUserKey (which is not enabled by default). EnableEventValidation does provide postback input related protections, but ViewStateUserKey actually ties it to the user session. Without ViewStateUserKey, you will notice the __EVENTVALIDATION nonce will be the same for any two users. With ViewStateUserKey, the value will be unique per user. -Original Message- From: Michael Sutton [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 3:59 PM To: Chris Weber; pdp (architect); full-disclosure@lists.grok.org.uk; WASC Forum; webappsec @OWASP Subject: RE: [WEB SECURITY] Preventing Cross-site Request Forgeries [ASP.NET crowd] The EnableEventValidation page directive (enabled by default since .Net 2.0) applies a nonce value for form validation and is also a strong control to prevent CSRF attacks. Michael Sutton Security Evangelist SPI Dynamics http://portal.spidynamics.com/blogs/msutton -Original Message- From: Chris Weber [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 6:12 PM To: 'pdp (architect)'; full-disclosure@lists.grok.org.uk; 'WASC Forum'; 'webappsec @OWASP' Subject: RE: [WEB SECURITY] Preventing Cross-site Request Forgeries [ASP.NET crowd] Nice article. For the ASP.NET crowd out there, the will be even more simple, one line of code. Set the ViewStateUserKey property in your base class or page and the unique token protections (similar to CSRF_Guard) will be provided for you. http://msdn2.microsoft.com/en- us/library/system.web.ui.page.viewstateuserkey .aspx This protection mechanism has been available for many years, since the Framework 1.1 -Original Message- From: pdp (architect) [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 3:16 AM To: full-disclosure@lists.grok.org.uk; WASC Forum; webappsec @OWASP Subject: [WEB SECURITY] Preventing Cross-site Request Forgeries 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] -- -- 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] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
