Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Error resolving "/burp/show/1" when non-default proxy port is used.

Jeffrey | Last updated: Apr 22, 2016 12:32AM UTC

I am having issues with the "Test in browser" functionality from CSRF PoC and "Show response in browser" functionality from proxy. Both of these seem to work fine with the default configuration of Burp set to listen on port 127.0.0.1 port 8080. However, when I switch the port to 8090 and change my browser proxy settings accordingly, I start getting ERR_NAME_NOTE_RESOLVED error's in Chrome. When I change the proxy port to 8090, there are two additional things I must do to get it to work: 1. Add "burp" to my hosts file so that I don't get the DNS resolution error 2. Append port 8090 to the request (burp says to navigate to "burp/show/1", which I change to "burp:8090/show/1") After thinking about it, the two changes that I had to make to get this to work seem reasonable. I don't believe Burp does any proxying of DNS requests or makes any changes to the hosts file, so it seems like it would be necessary to specify the resolution for the "burp" host in order for a URL like "burp/show/1" to resolve and attempt an HTTP request, which can then be intercepted by Burp. The required port is a little stranger the more I think about it. In my browser, all requests should be proxying through burp on the configured port. If "burp" resolves, then the request should pass through burp and be hijacked. However, when using port 8090 and resolving "burp" to a public web server, the request isn't hijacked. But when resolving "burp" to localhost and including the proxy port in the address"burp:8090" it works. I'd like to know two things: 1. What all needs to happen successfully for me to be able to type "burp/show/1" into my proxied browser and for the request to get intercepted as expected by Burp 2. Why does this work with the default proxy port (8080), but not with a different port In case you're wondering, sometimes I have two or three Burp windows open for different engagements, so I'd only be able to use the default port for one of them anyway.

PortSwigger Agent | Last updated: Apr 22, 2016 08:04AM UTC

Switching the listener port and changing your browser config in the way you describe shouldn't cause any problems for the request-in-browser feature. When the browser is configured to use a proxy, it shouldn't (per the spec) do any DNS resolution of its own, and should just send requests for (unresolved) domain names to the proxy. So Burp will get the incoming request for the burp domain name and handle it accordingly. Given what you've described (the name not resolved error, and having things work when you cause your browser to connect to the proxy host and port by changing the URL and hosts file) it sounds like your browser wasn't actually correctly configured to use Burp as its proxy after you changed the port number.

Burp User | Last updated: Apr 26, 2016 04:05AM UTC

Thanks for the reply! That is interesting about the proxy performing the name resolution. Definitely makes sense and was the piece I was missing. Using that, I queued up two chrome instances with different profiles. On the first one, I relied on the system proxy settings (/etc/profile.d/proxy.sh): export http_proxy=http://localhost:8090 export https_proxy=$http_proxy On the other browser, I used the extension I have been using for this, Proxy SwitchyOmega (https://chrome.google.com/webstore/detail/proxy-switchyomega/padekgcemlokbadohgkifijomclgjgif?hl=en). After copying a "request in browser" path (http://burp/repeat/1), I put it into both browsers that should have been proxied to the same address. As expected from your response, the browser using the system settings worked just fine, and the browser using the plugin failed with the same ERR_CONNECTION_REFUSED. I think its safe to conclude that the browser plugin is forwarding http requests burp, but that for some reason it isn't acting as a full proxy and Chrome is trying to resolve addresses instead of sending them to the browser. I tried a different proxy plugin, and it seemed to work fine. (https://www.google.com/search?q=foxy+proxy&oq=foxy+proxy&aqs=chrome..69i57j0l5.1503j0j7&sourceid=chrome&ie=UTF-8) Thanks for helping me get to the bottom of this. It's been driving me nuts for a while.

Burp User | Last updated: Apr 26, 2016 04:41AM UTC

I fixed the issue with ProxySwitchy, so I thought I'd document it here. Long story short, make sure you aren't including "<local>" in the bypass list for a connection. I'm not sure why adding this would attempt resolution before passing to the proxy, but it does. You can see more info and my conclusions in this short lived bug report: https://github.com/FelisCatus/SwitchyOmega/issues/764

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