Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

CSRF token extraction in forms responding with 302 redirect headers

A | Last updated: Dec 06, 2018 11:54AM UTC

Hi, I am trying to launch an intruder session on a csrf protected login form. The form uses the anti-csrf mechanism implemented by the Laravel framework, which basically uses a double token model (a cookie-base token, and a hidden form field token). Burp successfully manages the automatic update of the cookie-based csrf token transparently through its first session handling rule. I found several online examples that explain how to defeat csrf protections by using the reverse grep extraction method, which basically pulls out selected data from a response to intruder request X and injects it into request X+1. The problem resides in the protocol: the POST is followed by a 302 redirect, which instructs browsers to pull a refreshed form (GET), which contains the new "hidden field" value. The method described in several websites doesn't work because the grep extractor, which is triggered in the response to the POST sent by the intruder, is applied on the 302 response: the form data is not there yet so the extractor cannot pull it out. In the options of the intruder, there is a "redirections" area. I configured the "follow redirections" to "always". Then I started building a new "grep extract" rule. When desiging the rule, there is a "fetch response" button, which triggers a payload and allows us to locate the extraction area in the responses. However, and herein lies my problem, the response that appears after pressing the "fetch response" button is still the 302 response. It looks like the "always follow redirections" option does not apply to the "grep extractor" (and consequently, I wonder where it applies then). I would have thought that enabling this option in an intruder tab context would typically affect the grep extractor by letting me design the extraction rule after all 302s have been followed. It looks like a bug (activating the redirect in that tab should typically affect the grep extractor panel) but I cannot tell for sure. Or should I use another technique to capture the content of this "hidden field"? I am now almost considering setting up a session handler rule that would trigger a macro every time there is an attempt to POST on a specific url. the macro would then extract the hidden field, set it into a cookie or something alike, then I would use the payload processing in the intruder to perform some magic. But to be honest...this feels more like hacking Burp than using it correctly, and it will probably require tons of debugging before I can confirm it actually works. Any help/thoughts will be highly appreciated, thanks for your time. a

PortSwigger Agent | Last updated: Dec 06, 2018 12:05PM UTC

That's great! Glad you got it sorted. Yes, macros are a better fit for this than recursive grep.

Burp User | Last updated: Dec 06, 2018 12:21PM UTC