Burp Suite User Forum

Create new post

Burpsuite Pro Session Handling Rule Bug

Nishant | Last updated: Dec 19, 2020 10:11PM UTC

Hi, I have managed to successfully create session handling rules to auto-login to my application based on session invalidity and macros. However I'm noticing a strange behavior that after adding Rules, Macros etc. when I export the Project Options (JSON file) and load it next time I start Burp Pro, I can see my session handling rules to have been added too yet when I run the scanner the session invalidity check doesn't work i.e. the rules fail when I debug it in "Session Tracer" tool. However when I open the "Project Options" tab and click on "Edit" for my Session Handling Rule and click "Edit" again for the "Rule Actions" and do nothing and click "OK" twice so as to simulate a new session handling rule creation, I can verify that the rule works perfectly fine after that. And I have to repeat everything I mentioned above, every time I start Burp Pro. I have confirmed that in the tracer logs the responses from the server is same both the times, yet for the very first time the tracer says the rule didn't fire and after no-op edit, the rule is trigger along with the subsequent macros. Is this a known issue, how can we fix this?

Hannah, PortSwigger Agent | Last updated: Dec 21, 2020 10:52AM UTC

Hi Could you tell me the version of Burp that you are experiencing this issue with?

Nishant | Last updated: Dec 26, 2020 03:33AM UTC

Hi, Sorry for the late response. I never realized there was a reply awaiting my response. Anyways, my Burp Suite Pro version is 1.7.37

Nishant | Last updated: Dec 29, 2020 08:04PM UTC

Hi, I just confirmed that this issue also exists in Burp Suite Pro v2020.12.1. To reproduce the issue, I'm documenting the steps as follows: 1. Open Burp Suite Pro v2020.12.1 JAR. 2. Intercept a request via Proxy. 3. Select a request that needs cookies for authentication and send it to Repeater. 4. Go to Repeater tab, replay the Request and confirm that Response status is 200 OK. 5. Repeat the same request again but this time without the Cookie header (delete the entire header) and confirm that the Response is a 302 and Location header URL contains the keyword "signin". 6. Create a Session Handling rule to check the invalidity of the session by issuing the current request and match for the case-insensitive regex "signin" in the "URL of redirection target" 7. Go to Repeater tab again, perform Step #5 again and this time the Response is 200 OK again instead of 302. This confirms that the Session Handling Rule works fine (also cross verified using "Sessions Tracer" tool. 8. Export the "Project Options" to a JSON file and close Burp Suite. 9. Restart Burp Suite Pro and load the project options from the JSON file saved in Step #8. 10. Go to "Project Options" tab and then "Sessions" sub tab and confirm that the custom session handling rule is added and enabled. 11. Repeat Step #2 and Step #3. 12. Go to Repeater tab, replay the request without the Cookie header. 13. Confirm that the response is 302 with Location header containing url with the "signin" keyword. 14. Go "Project Options" > "Sessions" tab and open "Sessions Tracer" tool and perform Step #12. 15. Confirm that the Session Tracer rule shows the custom session handling rule is applied but session is calculated as valid instead of "invalid" and no rule action is applied. 16. Go back to the "Project Options" > "Sessions" tab, select the custom session handling rule and click the Edit button on the left. 17. Select the custom "Rule Action" and click Edit button on the left. 18. Do nothing, click "OK" at the bottom right corner to close the Rule Action editor window, then click "OK" at the bottom right corner to close the Session handling rule editor window. 19. Perform Step #12. 20. This time confirm that the response is 200 OK instead of 302. 21. Perform Step #14 22. Confirm that this time session is calculated as "invalid" and the correct rule action is applied. This proves the bug which is verified in Burp Suite Pro v1.7.37 and v2020.12.1

Hannah, PortSwigger Agent | Last updated: Jan 04, 2021 11:03AM UTC

Thank you for clarifying this issue. We've raised this with our development team and should have a fix in the next release.

Nishant | Last updated: Jan 04, 2021 07:55PM UTC

Thank you for the update.

Ben, PortSwigger Agent | Last updated: Feb 11, 2021 10:00AM UTC

Hi, We just wanted to let you know that the new Burp 2021.2 release should now have fixed the issue that you were experiencing with session handling rules.

Nishant | Last updated: Feb 15, 2021 09:02AM UTC

Thanks for the update. I will check it out.

Nishant | Last updated: Feb 16, 2021 12:31AM UTC

Hi, I verified the issue with the latest version (2021.2) and confirm that the issue is indeed resolved. Thanks for getting this done. I'm not sure if this the right place to raise this point that since this issue is resolved in the newest version of Burp Suite, it means our integration will break. In older version 1.7.xx we used to scan one HTTP request at a time with precise markers (insertion points) with selected issue indexes for scanner configuration to increase speed during regression especially while verifying bug-bounty or pentest reports in bulk. But now, since setting the scanner configuration is not possible via Extender APIs it practically makes our integration unusable. Earlier our scans were not parallel but atleast it was fast enough (based on our precise configuration) that we did not mind launching sequential scans. Since this feature is neither available in the Professional nor Enterprise it basically blocks our workflow. Manually marking insertion points, selecting issue indexes, launching scans and aggregating using the GUI is not feasible. Given the application's complexity, automated crawl and audit of URLs are often inaccurate and slow. Burp Suite was our primary choice only because of its rich extensibility features. Please let us know whether setting scanner configuration is going to be possible again along with insertion points through extender APIs so that we can look for some interim solution until then.

Hannah, PortSwigger Agent | Last updated: Feb 16, 2021 04:30PM UTC

Hi I've logged your interest in being able to adjust the scan configuration from the Extender API. This is a ticket currently in our backlog and is yet to be prioritized, so we cannot provide an ETA for when this functionality would be available. Currently, to be able to control the scan configuration you would need to launch a scan (crawl and audit) with the REST API, but you've said that that isn't a viable option for you.

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