While I would obviously prefer a Python or npm package or a Go binary - a lot of CLI tools I deal with are JARs, including all the CLI utilities for my company’s SAST solution. Trusting the cert at the OS level may seem like overkill for curl and wget (and it is), but it is also the easiest way to proxy CLI tools when you can’t disable trust (as we’ll see later). With the Burp CA trusted by your OS, you no longer have to use -k with curl or -no-check-certificates with wget and you will see HTTPS traffic in Burp: Copy the burpca.crt file to /usr/share/ca-certificates and then run:
#Burp suite for mac chrome install#
Select the “Trusted Root Certification Authorities” certificate store to install and trust the Burp CA.įor most distros, trusted certificates are in /usr/share/ca-certificates. On Windows, double-click on the DER file and select “Install Certificate”. Under “Trust” select “Always Trust” for SSL: Search the keychain for “PortSwigger” and open up the certificate. Then after importing it, you must trust it. If you select “System” it will be trusted by all users on the machine. On a Mac, just double click the downloaded DER file and OSX will prompt you to add the cert to the keychain. You are weakening the security of your OS. Installing and trusting the certificate is very OS dependent. Note: if you are using mitmproxy, the certs are already in ~/.mitmproxy Openssl x509 -inform DER -in r -out burpca.crt You can either export the variables first, or run them inline with the command: They pick up their proxy settings from environment variables: Both tools can easily be configured to point to a proxy and are “proxy aware”.
#Burp suite for mac chrome how to#
Example 1 - Proxying curl and wgetįor the first example, I’ll show how to proxy the old standbys curl and wget. If Burp is running on a different host or interface, you should be able to just replace localhost with the IP of Burp. In most of these examples, I have Burp Suite listening on localhost:8080 and am running the CLI tools from the same machine. The second step is often more difficult, but never impossible :)
![burp suite for mac chrome burp suite for mac chrome](https://4.bp.blogspot.com/-P8oqyrkvBnA/XMna01Yiw9I/AAAAAAAAD3k/z06b4DtB-Jok48JtPwE-ukpvEh4Y9OxDQCLcBGAs/s1600/burp-suite-Sessions.png)
If a CLI tool is not working as expected and the error messages are unhelpful, the problem can become obvious as soon as you look at the actual HTTP requests and responses it’s making/receiving. A lot of CLI tools for popular services are just making HTTP requests, and being able to inspect and/or modify this traffic is really valuable. However, I often want/need to inspect traffic that comes from other tools besides browsers - most notably command line tools. The general use case for a tool like Burp or mitmproxy is to configure a browser to communicate through it, and there are plenty of write-ups and tutorials on how to configure Firefox, Chrome, etc to talk to Burp Suite and to trust the Burp self-signed Certificate Authority. It can be extremely helpful to look “under the hood” at actual HTTP requests being made to make sense of complex APIs or to test that one of my scripts or tools is working correctly.
![burp suite for mac chrome burp suite for mac chrome](https://luckytorrent.info/wp-content/uploads/2020/01/Burp-Suite-Professional-v2.1.07.jpg)
I actually find myself using Burp more for debugging and learning than for actual pentesting nowadays. Intercepting HTTP proxies such as Burp Suite or mitmproxy are extremely helpful tools - not just for pentesting and security research but also for development, testing and exploring APIs.