Taras, On Wed, Feb 29, 2012 at 12:47 PM, Taras <ox...@oxdef.info> wrote: > 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.
This can be done as an "optional" step for the previously defined algorithm, something like a "double check" for the CSRF. I'm not saying that w3af should implement this algorithm, I'll let you guys decide which one is better ! > >> 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. Sure, it is! > >> 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 -- Andrés Riancho Director of Web Security at Rapid7 LLC Founder at Bonsai Information Security Project Leader at w3af ------------------------------------------------------------------------------ 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
