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

Is there any way to make the internal scanner use an external browser or specify a session cookie?

x | Last updated: Dec 02, 2021 08:51PM UTC

I am trying to run a scan on a web application that is only capable of Single-Sign-On authentication. I am able to access the application only through Firefox; I can not access it through the built-in Chromium browser. I believe this is because I can not add proxy bypass settings to the "--proxy-bypass-list" parameter that is passed as a command line options when the built-in browser is launched. You can view these command line options by navigating to "chrome://version" in the built-in browser (as well as any chromium-based browser). I believe that this command-line option is akin to Firefox's "No Proxy For" option in the Connection Settings. I thought that using Burp Proxy's "TLS Passthrough" would allow me to essentially bypass the proxy in the same way as Firefox's "No Proxy For" connection setting, however this was not the case, as even when I set the same host in "TLS Passthrough" the web app will not authenticate... If I could add command-line options to the built-in browser then that may have worked, but to the best of my knowledge there's no way to do this (such as modifying some configuration file to add custom parameters for "--proxy-bypass-list"). I say all that as background basically to ask if there is a workaround for this? There were two methods I thought of for a bypass but I don't know if either is possible: 1) Pass the authenticated session cookie created in the Firefox browser to the Burp Suite Scanner so that it will have an already logged in session to conduct scanning on. 2) Alternatively, if I could somehow tell the scanner to use Firefox instead of a headless built-in chrome instance (which is what I believe it to be using by default), then this would also be able to bypass the issue. Sorry for the long question, I wanted to try and be as detailed as possible. If anyone has any answers or suggestions let me know. If this feature does not already exist perhaps it is something the developers could consider integrating.

Uthman, PortSwigger Agent | Last updated: Dec 03, 2021 09:35AM UTC

Hi,

Thank you for your post.

You are correct in that browser-powered scanning relies on the Chromium browser. There is no way to change this since the logic for each browser would be different and our development team has focused specifically on Chromium.

Can you share some more detail on how the Firefox restriction is imposed? Does the app/site check the User-Agent header? Do you know why this is implemented at all?

What happens if you try to load the site in the embedded browser?

To set a specific cookie or parameter value, you can use session handling rules (Project options > Sessions). However, if the site/app has some browser detection logic to fully prevent the use of any other browser than Firefox then it might not work - I'd suggest double-checking this with the developers if you are working with them.

x | Last updated: Dec 03, 2021 10:06PM UTC

I do not know believe there is a hard browser restriction in place... I just think that for whatever reason the Firefox "No Proxy For" setting is somehow handling the traffic flow differently than the "TLS Passthrough". Because of this difference, when using the Built-In browser, the SSO server I am contacting sees Burp's CA certificate, or somehow recognizes that the traffic is being proxied, and drops the connection. I just tried to use the Project Options > Sessions feature and that seems to have worked around it for now. Perhaps the Burp developers could find a way to allow the modification of the built-in browser's start up commands in the future. There are a whole bunch of them that can be found here: https://peter.sh/experiments/chromium-command-line-switches/ (may not all be up to date). I think this would be a valuable feature.

Uthman, PortSwigger Agent | Last updated: Dec 06, 2021 09:19AM UTC