Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Upstream proxy configuration only passes URI and not domain/host

Felix | Last updated: May 09, 2017 02:00PM UTC

Hi, I have spent some time trying to configure an upstream squid proxy server in order to have a known source IP address for testing engagements, without relying on a VPN (unfortunately in my specific circumstances a VPN is not usable). I keep banging my head against a wall which is essentially created by the way Burp forwards requests to upstream proxy servers for connections to some TLS enabled web servers. It requires the upstream proxy server to be in "intercept" mode in order for it to extract the host name and therefore be able to forward the request correctly. Without "intercept" mode the following can be seen in Squid's access.log when performing actions such as Active Scan etc: 1494337670.692 0 321.321.321.321 TAG_NONE/400 4022 GET /redacted/anonymised/index.cfm?origin=mz57eud0%c1%81yk8vrflhip - HIER_NONE/- text/html The same activity (and same target) in Burp going via the proxy when Intercept mode is enabled looks like this: 1494337917.156 0 321.321.321.321 TCP_DENIED/403 4424 GET http://www.example.com/redacted/anononymised/index.cfm? - HIER_NONE/- text/html Unfortunately that then gets denied by the lack of authentication as seen above in the access.log and below in the cache.log 2017/05/09 13:51:57 kid1| NOTICE: Authentication not applicable on intercepted requests. Interestingly, when using a browser (not burp) that is configured either to use the upstream proxy directly or to go via Burp, there is not URI formation problem, as can be seen in the access.log: 1494337343.598 228 321.321.321.321 TCP_MISS/200 220655 GET http://www.example.com/ username HIER_DIRECT/321.321.321.321 text/html Intercept mode in Squid has the negative side effect breaking user-level authentication which means that without a heavy management overhead the proxy needs to be available to the whole Internet. It also makes the configuration of any upstream proxy far more complex than is needed. As a fix, I would suggest that when using an upstream proxy, instead of making requests to just the URI, make them to the entire URL (i.e. including hostname). This way, the proxy can have a very simple configuration, can have user-level authentication and work effectively. Thanks!

PortSwigger Agent | Last updated: May 09, 2017 02:31PM UTC

How are you generating the requests from Burp when the non-proxy-style requests are sent to the upstream proxy? If you use a browser via Burp Proxy, with an upstream proxy configured, then Burp will leave the full URL in HTTP requests, and so will send proxy-style requests to the upstream proxy. If you also send these requests to other tools (e.g. Repeater or Scanner) then those tools will work on the request containing the full URL. If, on the other hand, you use Burp Repeater to directly generate non-proxy-style requests and send these to an upstream proxy, then they will be sent as-is, in their non-proxy-style form. Basically, Burp only sends exactly the requests you tell it to.

Burp User | Last updated: May 09, 2017 04:11PM UTC

Hi Dafydd, Thanks for your response. Inspired by your response I have run a few more tests... Namely I started a fresh Burp session and ensured both Proxies (upstream in Burp and Burp in browser) were configured before any targets were accessed. I'm not sure it totally explains the situation, however, it seems that Burp had been using some requests I had made to the target from before I enabled the upstream proxy which did not include the hostname in the "GET" (etc) header. part of why it was so confusing to diagnose was owing to the fact that this only seemed to appear to be the case some of the time. Essentially, only some hosts were affected, and those appear to be the ones that use vhosts: the sites with a dedicated IP respond normally as they don't care about the hostname. At the time, these hosts also happened to be the ones using TLS which was entirely a red-herring and to make the situation worse, our internal nameserver failed in an unstable state whilst all this was going on. Ultimately, can I change this please from a bug submission to a feature request? An option somewhere (probably with the upstream proxy config) to force the hostname into the request header in HTTP requests. Thanks Felix

PortSwigger Agent | Last updated: May 10, 2017 08:28AM UTC

Thanks for this feature request. We'll look into the feasibility of adding an option in upstream proxy settings to normalize requests to proxy-style form when necessary.

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