Andres, please read inline

>> Every request inside user's area of web
>> application with params will be detected as vulnerable. I' have decided
>> to improve it (with making some research) and want to discuss with you
>> interesting topic - automation detection of CSRF flaws. My current view
>> of CSRF-detection process is:
>>
>> 1. Does request has cookie (e.g. session cookie)?
>> 2. Does request has CSRF token in query string of POST payload?
>> 3. If request has such token does web app check it?
>> 4. Same with header based protection (Referer/Origin)
>>
>> Interesting points are:
>>
>> * What can we consider as CSRF token? Currently I calculate entropy of
>> it (as for password strength) plus some fast string and dictionary checks
>> * Strict mode on/off - do we need to audit GET requests? Not always...
>> * How to determine that CSRF token is checked? I am thinking about
>> checking of response codes and diffs of responses (like blind SQL
>> injection testing)
>>
>> All experiments will be in separate branch and, hope, in nearest future
>> w3af will detect CSRF flaws much better:)
>>
>> Any comments here?
>

>      Tons of comments , since I've worked in this for Nexpose :) First
> of all, here's a comment on how AppScan does it [0] , which is
> basically a "swap the two sessions" technique. Here [1] I wrote on how
> we did it for Nexpose:

 >Posted by Andres Riancho in Nexpose on Jan 30, 2012 5:30:59 PM

There is about a month between your post and my letter in case that I 
didn't read it on Nexpose blog! :)

> In order to identify the vulnerability, Nexpose is going to follow
> these main steps:
> * Crawl the web application without credentials, store non-authenticated forms
> * Login to the web application with the user provided credentials
> * Crawl the web application keeping session state and store authenticated 
> forms
> * Clear session cookies
> * Login to the web application with the user provided credentials
> * Crawl the web application keeping session state and store authenticated 
> forms
> * For each form that can only be accessed after authenticating,
> analyze if it has an anti-CSRF token. The basic way of doing this is
> to check if it has a hidden parameter that considerably changed its
> value (using the two form instances gathered during steps 3 and 6)
 > * Report forms that don't have anti-CSRF tokens as vulnerable to CSRF

And you forget to add important part:
> Another approach includes performing HTTP requests to verify that
> the anti-CSRF token is properly verified by the application, but extensive
> testing showed that the accuracy of that heuristic was slightly lower
> than the one of the implemented algorithm and speed was reduced due
> to the need of more HTTP requests.

>      Those steps "sound easy" but there are many details that are not
> stated there, details that of course I can't disclose. You'll start to
> figure them out by yourself if you decide to implement an approach
> similar to [0] or [1].
I totally understand that it is not so easy as somebody may think.
But it same case it is really interesting to research and implement in w3af.

>      Implementing CSRF detection in w3af is somehow difficult since it
> won't be easy to implement it as an audit plugin because it needs
> (usually) more than one session, or a lot of information that is not
> usually available to audit plugins. It looks like we'll need a new
> scan phase.
I see that Nexpose and AppScan uses 2 phases approach to detect such 
flaws. And it generates 2xtime more requests to web application in 
discovery phrase. And we of course can implement it in same way in w3af. 
But in same time my approach is simpler and doesn't need one more 
session. I try to make more work without sending requests. And I also 
think that scanner must not only try to find CSRF token but also check 
that web app verify this token it before any action. What do you think 
about way which I have suggested?

> [0] http://www-01.ibm.com/support/docview.wss?uid=swg21298693
> [1] 
> https://community.rapid7.com/community/nexpose/blog/2012/01/30/nexpose-reaches-owasp-top10-coverage
>
> Regards,
>
>> [0]
>> http://w3af.svn.sourceforge.net/viewvc/w3af/trunk/plugins/audit/xsrf.py?view=markup
>> [1] http://w3af.svn.sourceforge.net/viewvc/w3af/branches/csrf/
>>
>> --
>> Taras
>> http://oxdef.info
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> W3af-develop mailing list
>> W3af-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>
>
>


-- 
Taras
http://oxdef.info

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop

Reply via email to