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=F22B0AC7234C98DFE11D665A3383B7E2Although 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:
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).