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
