Proxies - Bobo T. Jones

No surprise, it has not taken long for me to hit something of a productivity sandbar. The post I started writing for today is about proxies… specifically, web proxies for web application assessment work. The goto standard for this tool is Burp Suite from PortSwigger. I have linked to the Community Edition, which is the free version. I’ve never been a fan of Burp, even though PortSwigger has made a fair number of positive changes to the tool over the past maybe 15 years. But I still remember the version that would hang on large server responses or freeze entirely, which was problematic because it did not automatically save any logs or state. I lost a lot of work over those years and I am naturally wired to hold a grudge for a long time.

In preparation for this post, I looked at the following alternatives:

What I learned is that ZAP is not a serious tool, Caido is a bit fussy to set up and mitmproxy can possibly be used for protocols besides HTTP. What I realised while I was doing this is that web proxy tools are still pretty crap. Not in the sense that the tools themselves are crap; I’ve tried to build a web proxy and it sucks. Ideally, you want some of what a browser does but also some additional things a browser won’t do. These tools have their fans but I’m not the only person who gets frustrated with them – I know some pretty brave hackers who only use the browser’s developer console. Deep respect.

I shall explain. Web application penetration testing is a small sliver of offensive security. In an ideal world, the security audit function of a web application should belong to the company’s product security team. But there was a time in history when nobody had a product security team. And there are still companies – usually small ones – that still don’t have one. So the best alternative is a web pentest. Hopefully with source code.

What even is a pentest? Nobody actually knows. I can assert this with confidence because for every maybe 20 assessments I've done, I might maybe encounter one customer who knows what is going to happen. They're easy to spot because they have a packet waiting for me during the scoping call. I can count on one hand the number of customers who have done this over the span of 20 years. My short answer is, "I read your code, look for mistakes, imagine a test plan and build HTTP payloads to exploit those mistakes." Pretty fuzzy, eh? Pun intended.

Here’s the sticking point that’s blocking me: AI is going to replace this function. Which is what we actually want. Here are my reasons:

AI will do a more thorough job of auditing a web application than a human. And it will be faster. A web app with 500 unique routes and request handlers can be pretty thoroughly audited in 2 weeks with 2 competent people. I haven’t seen a web app that small since 2017. There will be some exploitable problems in a web app that an AI will not find, but it will get all of the easy stuff.

There are no accepted, industry-wide standards for how to run a web app pentest. We act like there are, but nope. There’s not even an industry-wide standard for what “secure web application” even means. There are some rough taxonomy of common failures and maybe some abstract recipe for how to test for them, but it is still the case that every web application is sui generis. In a class by itself. Which is exactly what you should expect of something that is the product of one person saying “go build this thing” and a team of persons guessing at how to make code do the thing. Once upon a time, you might have actually seen some engineering rigor in web applications. Then we got REST, where someone apparently noticed that RFC 2616 described a bunch of HTTP verbs nobody was using. I could rant at length about this (and I have), but ultimately this is still an evolving technology and we’re still making it up as we go along. Kinda hard to standardise anything when it won’t sit still.

Not all web app pentests are the same. This is the trickiest point for me to make. When I scope a web app pentest, I ask for all the documentation from previous assessments. I’ll just say it this way: some of these things are not like the other ones. In that some of these security firms are phoning this shit in. It rather bothers me that companies are getting ripped off. It’s a problem

Meanwhile, pentesting a web application is a slog. I kinda blame REST for this misery, too. While it is still the case that some Java apps can be prodded to emit an XML-formatted contract definition called a Web Services Description Language (WSDL) document, most of today’s APIs require developers to manually add decorators that generate a YAML or JSON-formatted contract definition. These are interchangeably known as a Swagger or OpenAPI specs. Contract definitions describe what valid HTTP messages look like for the request handler code at a given route. This is part of what I mean by evolving: older frameworks had better automatic contract generation. A SOAP service would just have a WSDL — you could hit ?wsdl and get the complete schema of every operation the service exposed. REST threw out that formalism in favor of simplicity, and now contract generation is opt-in, incomplete, or nonexistent. These contracts are aces for automated testing. But I guess the REST people don’t like the smell of SOAP.

Having said that, I have tested Claude – it can analyse a web app and generate an OpenAPI spec. It can probably generate templates for payloads, too, if you ask it nicely. But I’m a few paragraphs in and I’m still waffling on about how stupid web app pentesting is. I might have baggage.

setup

If you want to play with web proxies, start by installing WebGoat. This will give you something to test against. Notice that I’ve changed the WebGoat port to 8888 here; this is because pretty much all proxies listen on 8080.

docker run --name webgoat -it -p 127.0.0.1:8888:8080 -p 127.0.0.1:9090:9090 webgoat/webgoat

NOTE: I use OrbStack (not free). In the past, I have also used podman (free). Both are awesome. And since setting up test envs is a big part of appsec, I recommend learning one of them. Maybe I should add this to my post list.

Burp

Let’s do Burp first. It’s the Devil I Know. Download the community version for your OS. Follow the installation isntructions. Run Burp. Be annoyed by its splashes and prompts and terrible UI. The free Community Edition locks you in to a temporary project. This is fine. Defaults is fine. Ignore the prompt to update. Keep moving. Click on the Proxy tab, then the button labeled “Open browser…” (why do they keep moving this dang button?) This will launch a pre-configured Chromium browser. Try entering http://localhost:8888/WebGoat/. Maybe something will happen. This is about where I started getting really irritable because I got ERR_CONNECTION_RESET. And I remember there is something you have to do to make Burp load an app listening on a local port but I’ve completely forgotten what it is. If I figure out what it is before I finish writing, I’ll come back and edit this. Meanwhile, PortSwigger has a lot of training online. I’ve never done it. Obviously.

ZAP

Zed Attack Proxy (ZAP) (source) used to be an OWASP project. It was apparently sold to Checkmarx. Didn’t bother to look into why. I clicked the Download Now button and ended up with a disk image. MacOS Gatekeeper blocks ZAP because it isn’t notarized by Apple. There are two ways to get past it:

Open System Settings.app. Select Privacy & Security, scroll down, and you should see a message like “ZAP was blocked from use because it is not from an identified developer.” Look for a button labeled, Open Anyway. Click it, confirm, and you should be able to launch ZAP.
Strip the quarantine attribute that macOS applies to downloaded files with this command:

% xattr -d com.apple.quarantine /Applications/ZAP.app

ZAP looks somewhat similar to Burp but with a much less intuitive UI. Attempting to use it to poke at WebGoat gave me a lot of errors: