Block browser requests to Google during security analysis in Burp
How to stop Portswigger's Burp Proxy's built-in Chromium browser to leak information to Google's Safe Browsing during a web application penetration test?
When doing web application security research and penetration tests for customers, we sometimes get insights into tools we use that seem weird and undesired. A while ago we were testing a financial website with confidential data with the Mozilla Firefox browser and Firefox was sending the following requests whenever we downloaded a PDF from the website:
POST /safebrowsing/clientreport/download?key=%GOOGLE_SAFEBROWSING_API_KEY% HTTP/1.1 Host: sb-ssl.google.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/octet-stream Content-Length: 189 Connection: close blob:https://www.example.org/6f75423b-3828-5e4b-8241-3e633c684041___________ Dblob:https://www.example.org/6f75423b-3828-5e4b-8241-3e633c684041___ txt_download_name_file_overview.pdf [...]
As you can see, Firefox leaks the PDF file name we were downloading, the hostname of the website we were testing and some more binary data that could include a file hash. On one side we were happy that we found this privacy issue and could report it to our customer, because this browser behaviour affects normal users. On the other side we do not want our testing tools to behave like this. Safebrowsing can be disabled via the pentest browser's settings menu or by setting these values in about:config and it must be done for every web application test browser in use:
browser.safebrowsing.malware.enabled = false browser.safebrowsing.phishing.enabled = false
In the meantime the Portswigger Burp proxy we use regularly and write extensions for was updated to include a new feature: A builtin Chromium browser. We really appreciate the added usability and were happy to use this feature in a security analysis in a corporate Windows AD environment, where changing proxy settings was not allowed for the preinstalled browser. Fortunately because we asked our customer to install Burp with administrative privileges, the built-in Chromium browser of Burp could be used. However, we noticed that the preconfigured Chromium browser was again very verbose and contacted Google servers, especially during startup. As we would like to keep all information about our security analysis to our customers and ourselves, we avoid any third-party services wherever feasible. That's why we operate and use our own Burp Collaborator server, for example.
It is possible to disable the Safe Browsing feature in the browser used to perform web application pentests. However, if it is necessary to switch the browser, these settings must be changed there as well and the approach does not really work for the the built-in Chromium browser, because its settings are reset on every start. The easiest solution is to control traffic in the Burp Proxy: We can abuse the Upstream-Proxy setting found in "User options - Connections" in Burp for this purpose. While the following approach will block the requests from reaching the Google servers, they will still show up in the history tab of Burp.
Download google-blocking.json.
In Burp, go to "User options - Connection".
On the left of the "Upstream Proxy Servers" headline, click the settings and chose "Load options".
Chose the file you just downloaded and press "OK". Then, the upstream proxy settings look like in the screenshot below.
This configuration will redirect requests to most Google domains to TCP port 1337 on localhost, which is (hopefully) a dead end. It is possible to use the file as a Burp startup configuration, or even better, merge it with your existing startup configuration by editing the Burp settings JSON file manually. Then, your are able to use these Burp settings in new projects as well.
A drawback of the approach is that your test browser cannot be used for Google searches afterwards and it may break functionality if the tested sites requires resources from Google of course. However, it is recommended to use separate browsers for regular work and for web application testing anyway, because they are configured for different purposes.