Saturday, November 1, 2008

The Month of Burp Pr0n

The next release of Burp Suite is near to completion, and will be made available during December if all goes well. This is a significant upgrade, with major enhancements to several existing components, and some exciting brand new tools. In fact, the new release is the biggest step forward in Burp's history, with over 50% of the codebase being new code. It's been a marathon effort, believe me.

Every day during November, I'll be blogging about a different feature of the new release, demonstrating how the functionality works and how it can help you to attack web applications more easily and effectively. I'm also keen to get feedback on the new features and receive requests for further enhancements, so please leave comments or email me. Work on the final version is ongoing, so there is still time to change things and add new features if people have good ideas.

And by the way, anyone who asks for a beta version at this stage owes me a beer. All in good time.


antisnatchor said...

I would add a Flash analyzer such as Charles. Even if during my pen tests I use SWFintruder, I think a component like that could be useful in Burp too.

I would also improve the possibility to extend Burp using the interface that you exposed: maybe a bit more documentation, also because Burp is closed source and compiled with code obfuscation.

I'm definitely gonna buy your tool Daf, because I think is the most useful to do manual assessments.

Looking forward to see your news.

Enjoy your marathon ;)


Jabra said...

I would to see the the ability for Burpsuite to look for SQL injection, XSS in an automated way. After it finds something then you can manually verify it using the information it provides. It should also be smart about things like XSS on custom 404 pages. I can't wait to see the new version!


PortSwigger said...


You are absolutely in luck. Watch this space!

Anonymous said...

Excellent news! No shaving and lots of burp posts this month.

WRT features, I agree with antisnatchor, an AMF3 parser like the one in Charles would be a great addition. I'm not aware of any free tools that have one.

Keep up the great work :]

kuza55 said...

Is there any possibility to export/import data from burp?

For me, being able to export the request details from the Proxy is probably the most desired option, and preferably in plaintext so that I can easily parse them, pretty much what Paros has (so when I need to export requests I switch over to Paros).

Also, it would be nice to be able to decode .NET ViewState on responses as well as requests (since I end up intercepting both when I'm examining things, and I don't like having to submit forms to get Burp to decode the data).

PortSwigger said...



Re exporting request details, do you mean saving out the info in the proxy history table, or saving the actual request contents? Either would be pretty easy to add. In the latter case, presumably a plain text format with a unique single-line delimiter between requests?

Btw, you can already configure Burp to log all requests to file, in the Comms tab, which may meet your needs for exporting request info?

Re analysing response ViewState, already done in the new version!


Anonymous said...

How about an easy way to revert to a previous requests sent by the repeater / intruder. After I customize a request and send it through one of these tools, I loose any of those changes once I send a new request through to the repeater / intruder. Is it possible to include those requests in the history or even have an option once your inside the repeater to see previous requests that its sent?

PortSwigger said...


You can already do this in Repeater - just use the back and forward buttons to move through the request/response history.

kuza55 said...

Haha, god I suck, yes that's exactly what I was looking for, I think I need to sit down and read the manual >_<

And thanks for making such an awesome tool, :D

P.S. The spidering functionality will be much appreciated; I came to appreciate it a lot in paros when a client wanted us to look at all their sites, which numbered in the low hundreds; Paros' spidering functionality made it considerably easier since they were all built on a common framework and the only thing I really needed to know was all the pages on a site and if there was anything interesting I should poke at.

I'd list a whole list of things I would think you could throw into the spider to help find more results, however I'm not a fan of tool overlap and a huge fan of tool interopability, the problem at the moment is there's nothing to be interoperable with. Maltego looks very nice, and if it didn't cost so much, I would really have liked to build some of my own tools, etc into it and even release them.

However building on a closed source platform isn't really something that I find appealing, hell I'm not even really comfortable developing for a proprietary platform (I have nothing against them, I use them a lot, and it helps me get my job done, hell I use Burp a lot, and it's effectively closed, however releasing tools locked to closed platforms isn't something I'm personally comfortable with); CANVAS seems to have reached a nice middle ground, since it's open source, but still proprietary, but it's locked to everyone who can afford CANVAS, so you have a limited amount of people who contribute, etc.

Back to spidering though; I think there needs to be some kind of loose coupling between distinct recon and attack tools, and we need to start coming up with ways to integrate our toolset (I've become quite excited about tool integration and visualisation after having to work on some large-scale projects)

I think I'm rambling atm, but I think I need to find someone I can con into writing an open source Maltego clone. But then I'm living in an ideal utopia and I realise that everything costs money, etc, and someday I will reconcile myself to that, but somehow I don't want to release something only people who have purchased some existing tool can use for free (since you're essentially just doing free dev work for a company that's not paying you), and I don't want to start charging for things.

If anyone is still reading this; one day I hope to have some way to start off with a recon tool like Maltego (obviously with different transforms, but same interface), run a bunch of transforms (which would really just do database lookups or run tools, etc), then launch an exploit tool from within the recon tool (either something standalone, or more preferably something like Metasploit), from where I can pwn something, and then setup some kind of 'channel' that gets passed back to the recon tool, a channel could be something like a network proxy where you've owned a machine and you want to start doing recon on the other network, or maybe it would just be an SQL Injection 'channel' where you can start doing 'recon' on the database, etc. Or maybe the recon functionality should be built into a monolithic framework like metasploit, you wouldn't really loose *much* (other than the ability to reuse components in other tools).

Maybe some day I'll translate all this excitement into actual code, but right now I need to get back to studying for my exam tomorrow, wooo. >_<

P.P.S. Keep up the great work :)

Anonymous said...

This is really petty, but when I use the repeater in screenshots to include in a report I like to cut out extraneous white space. The reporter allows me to extend (resize) the request window lower, but is very limited in how high I can raise it. Would it be difficult to allow more resizing options in the windows?

kuza55 said...

While you're still soliciting suggestions I thought I might ask; would it be possible to add multipart/form-data encoding capabilities to burp so that we can simulate file uploads without having to use the browser?

PortSwigger said...


You can kind of do that already. If you intercept a multipart file upload request and send it to repeater, then you can edit the filename and contents and resubmit manually at will. There are some limitations in the current release's handling of multipart bodies (which will hopefully be addressed), but they shouldn't affect that basic attack.

Let me know if you had in mind something more elaborate. Cheers.

kuza55 said...

Yeah, and that's what I currently do; and after having a second look it seems I missed the fact that you could right click in the params tab and select change body encoding, *sigh*, I fail at reading documentation.

PortSwigger said...


Heh, that's actually where there are a couple of bugs in the present release. When Burp converts a URL-encoded body to multipart, the result doesn't quite comply with the spec, and some web servers don't like it. Also, if you edit multipart parameters in the param view, you lose the filename attribute of the uploaded file parameter, causing most web servers to reject it. Both these bugs are fixed in the new version. In the meantime, just intercepting a request in text form and manipulating it directly should be ok.

Anonymous said...

One "me too" for exporting request/response data. It would be very nice to be able to export a text file from the history panel that looks something like the output of `ngrep -q -W byline ...`, so that the entire history including request headers and parameters, response headers and body, etc., could be viewed and manipulated in one text file.

And, thanks for the great tool!