- CSRF Tokens using macros in Burp suite I
- CSRF Tokens using macros in Burp suite II
- CSRF Tokens using macros in Burp suite III
- CSRF Tokens using macros in Burp suite IV
We are coming back with our CSRF bypass using macros on burp suite, lets see how the test application looks like and what happens if we try to scan with the out of the box configuration.
We ended our last post pointing to a URL where we can find a search field in a form. You can access it in here. The page looks like the next figure.
If we open a browser (just pick one, I chose Firefox because is the one I use for my tests) and point it to burp suite using the proxy in the settings, we can see how is this form communicating with the “app” server side.
I am not going to detail here how to proxify the browser, you can find it just googling for it. To see how the application is communicating with the app server side you can use as well firebug (a firefox extension) or even the developer tools that you can find pressing F12 in your browser (chrome and firefox at least, I don’t know about IE).
As you can see in the figure above, there is a value set in the form in a hidden field called crsf_token (misspelling of csrf_token). This value is set to a different value each time you perform a search. If you try to scan this application you will find that only the first attempt is performing a valid query since you need to retrieve a valid token per each request. To scan the application you can use the scanner in Burp Suite or, if you don’t have the required license, use Zed Attack Proxy (ZAP) instead.
After running the out of the box scan you will realise that nothing of value is detected even though the application is flawed by a reflected XSS. You can check it just filling the search box with the classic:
So this is not working as expected, lets solve it programming a macro in our next post!