Friday, May 11, 2012

Testing CSRF aware webapps with Burp


Nowadays, is not uncommon to face websites protected using some variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.

The basic functioning of these webapps is to generate a random token submitted with each HTTP request, ensuring that the token is present and is valid for a given HTTP request.

Below is shown an URL including its associated token:

http://localhost:8080/injection_CSRF/inject.jsp?id=1&org.apache.catalina.filters.CSRF_NONCE=F22B0AC7234C98DFE11D665A3383B7E2
Although these protections help to mitigate effectively the risk of CSRF, they make almost impossible to analyse an application in an automatic or semi-automatic way, as this involves requesting an URL with a given token several times, which are discarded by the web server. Furthermore, a common action is to close the established HTTP session.

The only way to request a URL several times is to re-generate the associated token. One possible way of doing this is using the referrer header in order to go backwards identifying all the requests involved in the creation of the token and request them again in order to regenerate it.

Shown below is an example where a user has to click through two menus in order to reach the "inject.jsp" page:

  1. http://localhost:8080/injection_CSRF/index,jsp
  2. http://localhost:8080/injection_CSRF/index2.jsp?org.apache.catalina.filters.CSRF_NONCE=2AC1162C4CA176122F2BAA591B1F360E
  3. http://localhost:8080/injection_CSRF/inject.jsp?id=1&org.apache.catalina.filters.CSRF_NONCE=1EB3952B5BB391C7936A862DF8940DF0
In order to perform an automatic scan of the third request, the two previous requests must be performed sequentially as each of these requests contains a new generated token needed for the next request, forming a token chain.

A POC in the form of a Burp suite plugin has been developed to verify this approach, it can be downloaded at https://github.com/xmendez/misc. This plugin has been successfully tested against a simple vulnerable application using tomcat CSRF protection (all the requests in the token generation chain must be requested before testing a given URL).

It should be noted however that this code is a POC and it requires further development in other to be able to work against real environments (any link of a webapp with this behavior is appreciated).

Wfuzz 2.2.0 released

I'm pleased to announce a new version of WFuzz! Wfuzz has been created to facilitate the task in web applications assessments and it...