Hi, A thought; if the user specifies two sets of credentials, it wouuld be simple to check whether a page, when accessed with two different sessions, are identical*. If they are => that's csrf. Similarly, if the page containing the form can be accessed without credentials, and it also is identical, that is *not* csrf (example could be an anonymous feedback form). This way, it wouldn't be necessary to actually submit forms, and could be a first stage before going more in-depth and submitting stuff.
* Identical : the same set of parameters in a form, url- and form-parameters On 03/08/2012 08:45 PM, Achim Hoffmann wrote: > Andrés, Taras, > > please see inline below. > > Achim > > Am 29.02.2012 20:34, schrieb Andres Riancho: >> 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 > ... >> Yes, I agree, but it is IMPOSSIBLE to detect all of them in an automated way. > Sell, someone needs to start somewhere :) > > ... > >>>> 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? > Ok, let's go back a step. > CSRF is only dangerous if the request is send by an authenticated user. > If you have CSRF in an application which can be used anonymous, I won't > qualify that as CSRF as it can be used by anyone anyway, no benefit to > craft an CSRF attack. > > Said this, CSRF occours in authenticated sessions only. Means that the > requests needs to carry the current session ID somehow. It doesn't matter > if the session ID is in a cookie, in basic auth or somewhere else. > CSRF is possible if the attacker manages to craft a request which when > "seen" by the browser with an authenticated session, send the request and > the browser automatically adds the session ID (aka credentials) to the > request. > > I'm pretty sure you all know how it works, at least when the session ID > is in a cookie, so my description is just a reminder, hopefully. > >>>> * 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? > I mean if the request subject to CSRF is denied somehow, CSRF does not > take place. > >> It is not trivial to say: "If the >> request fails do X" if you don't define "fails". > Agreed. This is often a bit tricky, as you need a pattern for a working > CSRF and one pattern for a failed CSRF. > Can some of the "grep"-functions in w3af be used to check for common > error strings in the response? > These checks are subject to false negatives. But CSRF is ahrd to detect > automatically. > >> 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. > With "controls", do you mean some kind of business logic? > If so, the check will show that CSRF is not possible in a simple way > even if the application does not use anti-CSRF token. Perfect. > >>> Then continue >>> 4. check for anti-CSRF tokens >> What do you mean in this step? What should w3af do if it finds tokens? > A lost of such tokens can be circumvented easily. It's a pain. > Methods to circumvent tokens: > + re-use previous fetched token > + attacker gets his own token (which is different from the victim's token) > and uses that (if it works, you also identified a poos session manageent:) > + get a new token and inject it > (note, this just proves the possibility to circumvent anti-CSRF token, > in practice it may be difficult to exploit automatically) > + use a random token (have often seen this with X-CSRF or X-JSON headers:) > + use duplicate tokens: duplicate cookie, duplicate form parameter, > + exchange the "channel": if token in cookie, write it as form parameter, > and vise versa > > I know, this all needs sophisticated programming. So is the programming of a > proper CSRF protection, and it often fails today. All above seen in the wild. > CSRF protection and detection is nothing for script kiddies:) > >> What if it doesnt? > (doesn't find a token) > > When there is no token, then w3af just needs to check the response of the > request subject to CSRF. As said above: this check may come out as false > negative. > >>> 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? > Hmm. My description was too lazy. > Step 3. identifies URLs which are not seen when crawling the application > without authentication. If a crawler would find them (I mean simply, not > by brute forcing directories and files), the hole business logic is crap. > So step 3. identifies all potential CSRF-able rewuests. > > In step 5. we only have those left which have tokens. They need to be > processed with special algirithms (see above). > >> If there are only vulnerable >> to CSRF they were filtered in 3? > Yes. > > ... > >>>> 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". > For sure. > I just wrote down what I see in daily testing. Feel free to implement > what's possible and reliable. > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
