So recently I wrote about writing burp extensions and I taught this through writing an extension to deal with CSRF tokens that are in each page, so as you navigate the site or fuzz a function you have to extract a token from each page to include it in the next request.
That’s not the only way to implement tokens though, and today I came across “the other way” during a Penetration Test so modified my original code and figured I’d share this version too!
I wrote a very simple burp extension that can pull a token a CSRF token out of a response and update the next request with that token. It’s designed to be a simple as possible so it works for my lesson on writing burp extensions and if you’re lucky then all you need to do is update the script with the name of the token your target application uses and you’re good to go but it’s designed to be as easy to tweak to your needs as possible. I also wrote about how to install custom extensions here if you’ve not done that before, just copy and paste the below code into a file called csrftei.py and load that file into burp! The code is all available below and should be nicely commented to explain how everything works:
Recently I wrote a quick HowTo about dealing with using Burp Suite against an application that invalidates your session whenever it spots a potential malicious payload. I wrote that a Burp Macro that can perform Automatic Reauthentication can overcome that issue. Another common issue that gets in the way of performing penetration tests against mobile applications is having to deal with anti cross-site request forgery tokens. These are tokens that an application embeds in a response and expects to see in the body of the subsequent request, if the token is ever missing or incorrect the request is ignored. This interferes terribly with Burp Suite tools such as repeater, intruder and scanner as by default these don’t handle the tokens and therefore the requests are all ignored. I get around this issue through the use of simple custom burp extensions and I wanted to share some notes about how surprisingly simple this is!
Today I found a possible Cross-site Request Forgery vulnerability in a web application, however – the application expected JSON as its input. The fact that the input is JSON means that the attack is a little bit more complicated, the browsers built in protections get in the way a little more. So here’s some notes and tricks which might help a little!