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
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
> * 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. Then continue
4. check for anti-CSRF tokens
5. call remaining URLs with previously identified tokens
> * 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 ;-)
>
> 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
Hope this helps to improve the plugin.
------------------------------------------------------------------------------
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
