Achim, On Tue, Feb 28, 2012 at 5:36 PM, Achim Hoffmann <webse...@sic-sec.org> wrote: > Taras, Andrés, > > first of all CSRF is not limited to > - requests with parameters > - POST reqeusts > - GET requests > - requests with cookies > - requests for authenticated sessions > > more details see inline below
Yes, I agree, but it is IMPOSSIBLE to detect all of them in an automated way. > Achim > > > Am 28.02.2012 20:42, schrieb Andres Riancho: >> Taras, >> >> On Tue, Feb 28, 2012 at 4:27 PM, Taras <ox...@oxdef.info> wrote: >>> Hi, all! >>> >>> There is CSRF plugin in w3af [0]. The problem is this plugin is too >>> simple: >>> >>> "The simplest type of XSRF is checked, to be vulnerable, the web >>> application must have sent a permanent cookie, and the aplicacion must >>> have query string parameters." >>> >>> In most cases it will be better to *not use it* because of a lot of >>> false positive detection errors. >> >> Completely agree. I was actually going to deprecate it. >> >>> 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: >> >> In order to identify the vulnerability, Nexpose is going to follow >> these main steps: > > IMHO following algorithm -if done in this sequence- is a bit hopeless. > >> * 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 > > To detect potential CSRF, reverse above steps: > 1. login to application > 2. crawl application > 3. call all URLs identifies in 2. without credentials How do you define "without credentials" here? Is that without the "Cookie: " header? >> * 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) > > All URLs failed in step 3. above are either not CSRF-able or use > further protection like anti-CSRF tokens. How do you define failure here? It is not trivial to say: "If the request fails do X" if you don't define "fails". In most cases ALL of these will fail NOT because of Anti-CSRF tokens but because of authorization controls, so this step 3 doesn't make much sense to me since it is "wasting" HTTP requests. > Then continue > 4. check for anti-CSRF tokens What do you mean in this step? What should w3af do if it finds tokens? What if it doesnt? > 5. call remaining URLs with previously identified tokens So... to step 5 I'll only get URLs that are both vulnerable to authorization failures AND CSRF, right? If there are only vulnerable to CSRF they were filtered in 3? >> * Report forms that don't have anti-CSRF tokens as vulnerable to CSRF >> >> 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]. > > Guess it's improved slightly now ;-) Nope, or I didn't understood it :( >> >> 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. > > Further keep following in mind: > + check CSRF with Basic/Digest Authentication > + check CSRF with certificate authentication > + if cookies are used; block cookies and check with URL parameter > + if 5. above fails, get new anti-CSRF tokens with authenticated > session, and check them with an unauthenticated request > + take care for (I'd call them) pseudo anti-CSRF tokens like special > HTTP headers (which are mainly constant values) > + consider request where "parameters" are in the INFO_PATH Yes, but at first we want to at least be able to identify the "most trivial version of CSRF". > Hope this helps to improve the plugin. Regards, -- 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
