[Webappsec] [WEB SECURITY] Preventing Cross-site Request Forgeries
Stephen de Vries
stephen at twisteddelight.org
Mon Apr 2 00:01:03 EDT 2007
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.
On 30 Mar 2007, at 17:16, pdp (architect) wrote:
> I briefly covered how simple it is to prevent CSRF attacks. Hope that
> you find it useful.
> pdp (architect) | petko d. petkov
> Join us on IRC: irc.freenode.net #webappsec
> Have a question? Search The Web Security Mailing List Archives:
> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss
> [RSS Feed]
Stephen de Vries
E-mail: stephen at corsaire.com
Tel: +44 1483 226014
Fax: +44 1483 226068
More information about the Webappsec