[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

--------------070602020501020506010003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Very nice response, Stephen. I'm always impressed with the depth of your 
commentary. You are in the zone.

- Jim

Stephen de Vries 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]
>>
>>     
>
>   

--------------070602020501020506010003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Very nice response, Stephen. I'm always impressed with the depth of
your commentary. You are in the zone.<br>
<br>
- Jim<br>
<br>
Stephen de Vries wrote:
<blockquote
 cite="midFC1BEA02-E211-434E-B67C-C529EA66F0EE@twisteddelight.org"
 type="cite">
  <pre wrap="">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 (<a class="moz-txt-link-freetext" href="http://";>http://</a> 
<a class="moz-txt-link-abbreviated" href="http://www.jboss.com/products/seam";>www.jboss.com/products/seam</a>) which defines a "conversation" state in  
addition to the usual session state.  Spring webflow does something  
similar (<a class="moz-txt-link-freetext" href="http://www.springframework.org/webflow";>http://www.springframework.org/webflow</a>) 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:

  </pre>
  <blockquote type="cite">
    <pre wrap=""><a class="moz-txt-link-freetext" href="http://www.gnucitizen.org/blog/preventing-csrf";>http://www.gnucitizen.org/blog/preventing-csrf</a>

I briefly covered how simple it is to prevent CSRF attacks. Hope that
you find it useful.

-- 
pdp (architect) | petko d. petkov
<a class="moz-txt-link-freetext" href="http://www.gnucitizen.org";>http://www.gnucitizen.org</a>

---------------------------------------------------------------------- 
------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:  
<a class="moz-txt-link-freetext" href="http://www.webappsec.org/lists/websecurity/";>http://www.webappsec.org/lists/websecurity/</a>

Subscribe via RSS: <a class="moz-txt-link-freetext" href="http://www.webappsec.org/rss/websecurity.rss";>http://www.webappsec.org/rss/websecurity.rss</a>  
[RSS Feed]

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

--------------070602020501020506010003--
Brought to you by http://www.webappsec.org
Search this site