Message-Id: <FC1BEA02-E211-434E-B67C-C529EA66F0EE@twisteddelight.org>
Date: Mon, 2 Apr 2007 11:01:03 +0700
From: Stephen de Vries <stephen@...steddelight.org>
To: pdp (architect) <pdp.gnucitizen@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk,
	"webappsec @OWASP" <webappsec@...ts.owasp.org>,
	WASC Forum <websecurity@...appsec.org>
Subject: Re: [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: stephen@...saire.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/

Powered by blists - more mailing lists