When hunting security issues or checking applications for potential privacy violations, the first tool I reach for is a web proxy. I frequently get asked about the tools I screenshot in these posts, and asked about my process, so I decided to share the basic steps I take to test a web application for security or privacy issues.

This information is targeted at someone with basic knowledge of the HTTP protocol and how the web works. It also assumes familiarity with common website vulnerability classes like the OWASP top 10. Some programming helps too, but isn't required.

Web Attack Proxies

When I first started in web app security, I just used my browser and the developer console for all testing. This can work, but sure makes it a lot harder to find and exploit vulnerabilities!

Web attack proxies are configured to be an intermediary between your browser and the target site, capturing all requests and responses made between you and the site. This let's you quickly inspect data flows, modify data in flight, and automate tests or other tasks. They also typically include a ton of other advanced features, like decoding or encoding data, passive and active vulnerability scans, and more. I'll only touch the surface of these options today, but once you start using a proxy it's easy to learn more!

There are three that I use on a regular basis:

• Burp Suite: The industry standard. The community version is limited in many ways, but is still excellent software. This is my normal go-to proxy.
• OWASP ZAP: Fully open source, with many of the same features as Burp. Sometimes it's even ahead in some areas.
• mitmproxy: I've been trying to do more of my proxy work in mitmproxy lately. It's very automateable and fully open source.

Using BurpSuite

Let's start with Burp. It's pretty easy to use and beginner friendly, without sacrificing advanced features. Download it via the link above and fire it up. Once it opens, click through to a temporary project and select the "proxy" tab.

You can configure your normal browser to use Burp, by setting the proxy to localhost:8080 and installing the generated Burp certificates (downloaded by navigating in that same browser to localhost:8080), but burp includes a built in chromium browser all setup correctly. I'd start by clicking the "intercept is on" button to disable intercept (it will pause all connections while you inspect the traffic, making the browser appear to be frozen) and then click open browser.

Now, lets try attacking the vulnerable OWASP application Juice shop. Open https://juice-shop.herokuapp.com/#/ in the burp browser.

Reconnaissance

The first step in bug hunting is understanding the application you are testing, and where it might have weaknesses. Normally, I browse around a site clicking various links and looking for areas that look interesting. A few things I immediately check out:

• Login forms or any kind of authentication flow.
• Any forms I can submit (feedback, lead generation, etc). I submit every form with some valid test data so I can store the request in the proxy.
• Any link that gives any kind of error (401/Unauthorized can be interesting to look for auth bypass, 500 server errors might indicate something exploitable, etc).
• Any URL that looks like it might have a unique ID in it - thing like site/product/1 or product?id=1 in the URL.
• Any page that includes data submitted in the URL or a request on the page, or includes something that looks like a filename or url. Something like view?file=thefile.txt

I'll sometimes also spin up a scan like dirbuster if the site allows automated tools, but they can be pretty heavy sometimes. A few files to check for manually:

• .git directories
• .htaccess files
• robots.txt and anything interesting in it
• If you know the software stack, configuration files for that stack.

While looking around the site, if something looks particularly interesting, I may dive right into testing. Definitely take note of anything you want to return to.

As you have browsed around in the Burp browser, your "target" tab has been filling up with every page visited (request & response is saved) and the proxy->HTTP History has been also keeping every request in order.

Finding & Exploiting a Vulnerability

Juice shop is full of vulnerabilities, so you should find plenty to play with. I'll start right into the authentication flow, and submit some fake username to log the request in the proxy.

Juice Shop is interesting in that every request isn't stored in the target tab - so for the login form I have to look at the HTTP request history, since I didn't see the post request where I was expecting.

In the below gif, you can see me find the login request, move to the repeater tool, run the request again with normal input, then with some special characters, revealing an error message that indicated SQL injection might be possible.

It won't always be so simple - in this case we see a SQL error message clearly. It might also have presented exactly the same information as before (invalid user) while still being vulnerable. Usually, I would probe the form with several different inputs looking for variances in the response before moving on.

Keep in mind that a form like this can have more than just a SQL back end. A key part of testing is forming a mental model of the various technologies in use on the back end, and how they fit together. SQL is pretty common, but I have also seen noSQL (mongo), XML, file system, even network requests from a form like this. Each will have a different attack surface.

Let's do the same thing, but with mitmproxy

If we wanted to automate the above tests in some way, or do any kind of brute forcing, we would need to upgrade to Burp Pro (which is worth it!). But we could also use a different proxy. ZAP works pretty similarly to burp, but mitmproxy looks a little different. Here's the same flow in mitmproxy:

Mitmproxy requires a little extra setup - you'll need to install their CA cert into the browser you are using by navigating to mitm.it once you have the proxy configured in your browser.

It's a little harder to follow, because most interaction is with the keyboard. mitmproxy mostly follows vim keybindings. r replay's the request, e enters the editor, and the arrow keys or q navigate between screens.

Finding Privacy Violations

When testing for privacy issues in applications, the setup is the same: configure the application (or the entire machine) to put all network requests through the proxy. Use the application normally for a while, and monitor the flows.

This won't work as well if the application doesn't use the HTTP protocol (in which case, network monitoring tools or injecting into the process are required), but I find almost all applications use HTTP primarily.

As you use different functionality in the application or tool, watch the network requests and read through the request and response data carefully. Check URL parameters, cookie information, and data in the request headers and POST data.

This is often where decoding tools come in. Common encodings I have seen (where tools try to hide their privacy violating practices) are base64, Hex, and URL encoding. Noticing what action generates what request can give a hint as to what data is being sent.

Conclusions

And that's the basic workflow! Of course, there are many tools that help with finding specific classes of bugs, or help inspect particular tech stacks, or automate particular tests. I think that when first starting to hunt security bugs, it's good to understand how to do it manually, then move on to the more powerful tools to automate away the repetitive tasks you find yourself doing.

What other tools and methods do you like when bug hunting?