The following is a version of my CSRF Extractor Burp Extension that works for remote tokens, the original sequential tokens version is available here. The following code is explained here.
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 …
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 …
Often abbreviated to CSRF and often pronounced as “Sea-Surf” is an attack against a Web Application that abuses an application’s trust in the user. An attacker’s aim is to cause a function to execute on the application using the user’s authentication credentials simply by causing the user’s browser to request that function in the normal way, but from a malicious site.
Same-Origin Policy (SOP) is a critical part of the security implemented within a web browser. It’s the part of your browser’s security system that prevents malicious pages from reading confidential information from other sites. So thepiratebay.com can’t read data from barclays.com because it’s blocked by SOP.
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!