Recently, I had the privilege of attending an Advanced Web Application Security training session at NorthSec which made heavy use of Burp Suite Pro. Even the community version of Burp Suite is terribly useful for pen-testing your sites before deployment, but I have personally found it difficult to find solid tutorials on how to use it, so I thought I would give a quick primer on it for totally new users. Below, I give you just a quick taste of what the Burp Suite Free Edition can do by exploiting a simple Reflected XSS flaw with it. (Usual caveat: please don’t use this tool to hack websites without the owner’s explicit permission, and certainly don’t commit XSS sins on other people’s sites, as that is highly illegal.)

Install the Target

To show off Burp’s functions, I installed the Damn Vulnerable Web Application, which you can download yourself to follow along. For these purposes, I have set the security level to “medium” under DVWA Security on the left-hand side. I’m using Firefox to demonstrate, which is almost like cheating  Chrome blocks simple XSS submissions with built-in protections. Because the point of this post is to show you how to use Burp, though, I’m okay with doing an incredibly cheesy flaw like this.

Find the Entrypoint

First, let’s take a look at the page itself and see how it works. There’s an obvious entrypoint in the submission field, which we can see in the url (“name=xxxxxx”). Here’s a naive attempt to exploit this entrypoint with XSS.

It doesn’t work, of course, because the Damn Vulnerable Web Application is set at medium security. We could keep entering attempts at XSS here one by one, but there’s a much easier way to do this with Burp Suite.

Set up Burp Suite Proxy

First, I have to change Firefox’s proxy settings under Preferences > Advanced > Network > Connection > Settings to allow me to intercept traffic and mess around with it in Burp Suite in the first place. Here are the settings you’ll want.

Now, I start up Burp Suite and set it up as a temporary project. The first thing I’m going to do is navigate to the Proxy tab and turn off Intercept so that the button reads Intercept is off. I would rather just go through my HTTP history, instead of pausing every request I make.

Find the Request in HTTP history

Now that Burp Suite is storing my browser requests, I reload my exploitable page in Firefox with my attempted XSS, just to get a base to work from. I take a look at my HTTP history tab, and sure enough, the request is there!

Send the Request to the Repeater

Now that I have my request, I can send it to a bunch of different places, just by ctrl-clicking (or right-clicking, if I happen to be on Windows). In this case, I’ll send it to the Repeater tab, and take a look at what it shows me.

Hello there, request. In the Repeater window, Burp allows me to edit a request directly and repeat it as I like. This isn’t as useful for complex requests — you would want to use the Intruder tab for those — but it’s perfectly serviceable for our easily-hackable site, and worth using when you’re in the exploratory stage of a hack.

Above, you can see how my request and response appear in the Repeater. I’ve highlighted the relevant bits.

Change the Payload

Obviously, this attack didn’t work, as we can see that the initial script tag has been stripped out of the HTML response. It’s fair to assume that there is some kind of filtering going on server-side that doesn’t like that script tag, so I’m going to change my XSS payload to something less naive.

There’s a problem with this request now, though — my “name” attribute isn’t encoded properly. I could just go to the Params tab and edit it there, but I wanted to show you guys a neat trick you can do here in the Raw window (and from a lot of other places in Burp too). If you highlight your payload, you can ctrl-click (or right-click) and encode your payload using one of any number of encoding schemes. In our case, we are url-encoding the payload.

After encoding, I can see the result below, and resubmit my attack.

Now we can see that the request seems to have gotten through! The payload appears in the response as I originally wrote it. To make sure, I’ll open Firefox and enter the attack manually, to see if the javascript fires.

There it is! My javascript got delivered!

This is a pretty basic flaw, but you can already see how useful Burp Suite might be for testing out your sites. We went through plenty of more advanced ways to use the tool, but those are probably a subject for another day. For now, just enjoy the ability to intercept, edit, and encode your requests directly!

Featured image from PortSwigger Web Security, the makers of Burp Suite.
Conference Technology Development