Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

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

[Solved] I couldn't derive the final method through the original support article (https://support.portswigger.net/customer/portal/articles/2906338-using-burp-s-session-handling-rules-with-anti-csrf-tokens), but the additional information provided in this answer (https://support.portswigger.net/customer/portal/questions/17408949-burp-suite-anti-csrf-post-) by P.J. to a previous request helped me understand the last piece of the puzzle. Things I hadn't understood from reading the original help article, which could help future readers: 1) When you set macros, you can configure them to be triggered automatically before specific requests (using the scope tab when defining the macro) and only within specific modules (the repeater, for debugging, and the intruder, for execution). 2) The parameter settings in the macro designer allow you to override not only cookies but also parameters (e.g.: form values) that will be sent in the "real" request. 3) You can test the setup by opening the session tracer, and triggering your attack manually in the repeater module. The session tracer will show you how the events will trigger and their effect (e.g.: 1) press to send the attack 2) interception of the attack request by the session handler 3) macro triggered 4) fields extracted from the response 5) attack request modified with the new fields 6) attack request leaves Burp 7) Beer.). a. p.s.: My apologies if this post looks very similar to a previous discussion, I hadn't made the connection with the 302 redirections + meta tags. p.s.: +1 Burp team for how you have engineered all this together!

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.