[Webappsec] [WEB SECURITY] Preventing Cross-site Request Forgeries

[Arian J. Evans]

Nice response Stephen. The Spring framework workflow has a lot of potential
for this. Seam currently is weak to session fixation but that could be
fixed.

These frameworks give us a design-time way to specify these behaviors, but
how do we solve for existing weak platforms: One promising solution is the
Entrust Fraud Detection framework. I believe prior to purchase it was called
something like "Business Rules". I've emailed the list about it before but
it seems largely ignored as a solution:

http://www.entrust.com/fraud-detection/index.htm

On existing platforms with fundamental design weaknesses enforcing workflow,
the TransactionGuard platform shows promise for learning about and detecting
these types of abuses.

Another option would be the functionality we described and implemented in
our Paraegis proxy project, which probably needs better documentation than
our BH slides and source. (At this time I am unsure if we will ever revist
due lack of interest by framework devs, which is where my gut tells me this
needs to wind up)

The smartest things to do would be for someone to take our code/these
concepts and integrate them into a Spring/Struts style framework with an API
to define use, and token properties are set accordingly (automatically).

I think it would not be hard to abstract out a meta-use case (logical flow
of pages, how many times back-button should be supported, etc.) and define
all your token security properties accordingly.

There's at least one ISV of banking/online bill payment that has implemented
a solution into their platform similar to Entrust Fraud Detection. It is
capable of locking down and blocking requests, and gives spiders and
automation fits. (it appears a much more rudimentary HTTP property-based
solution, but I haven't seen the code so not completely sure what it makes
decisions based upon)

A little time with Google could find you the vendor and more details. (Hint:
the name is similar to the name of Entrust's solution) </nda>. These
solutions all have promise.

I am unsure how I feel about these approaches at present (as an overall
approach). Currently they are reactive, and serve to mask certain types of
issues without fixing them by obfuscating run-time generic testing attempts.

They also provide a more session-oriented and clear forensic trail.

Both of these are a good thing, but my vote is still out one whether or not
they generate a false sense of confidence by the ability to false negative
webapp scanner results by masking real issues.

Arian J. Evans
solipsistic secure software sophist



On 4/1/07, Stephen de Vries <stephen at twisteddelight.org> wrote:
>
>
> 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 at corsaire.com
> Tel:    +44 1483 226014
> Fax:    +44 1483 226068
> Web:    http://www.corsaire.com
>
>
>
>
> _______________________________________________
> Webappsec mailing list
> Webappsec at lists.owasp.org
> http://lists.owasp.org/mailman/listinfo/webappsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/webappsec/attachments/20070402/9c83459e/attachment.html