We are hiring!

The development team that brings you Burp Suite is expanding. Why? We're brimming with great ideas for features that we want to add to Burp, and we just can't add them quickly enough. With more people, we'll be able to deliver the next generation of amazing features even faster than we have done in the past.

We are looking for a mix of experienced developers, web security testers, and novice programmers to work on Burp. The common denominator: you must be outstanding at what you do and set the highest possible standards for your work.

• Are you a student looking for a summer internship working on great software and learning from industry experts? Read more.
• Have you worked for a year or two as a software developer, or looking to start soon? Read more.
• Are you an experienced Java software developer who is looking for a new challenge helping a growing team to continue delivering an exceptional product? Read more.
• Are you a web security tester who loves writing great tools? Read more.

Lots of regular Burp users fit that last bullet - great hackers who are already writing Burp extensions or their own tools to use alongside Burp. If that pretty much sums you up, we'd love to hear from you.

If you aren't sure whether we're right for you, read why you should work at PortSwigger Web Security.

For more information, please contact: careers@portswigger.net.

Burp Suite is on a feature roll!

Over the past month, we've added a wealth of new features to Burp Suite Professional. The most notable of these additions are:

• A new cross-site request forgery (CSRF) technique using cross-domain XmlHttpRequest, to enable CSRF file upload, and other attacks.
• DNS tunnelling over a SOCKS proxy (to access TOR hidden services, etc.).
• Support for automatic decompression of compressed request bodies.
• Support for .NET DeflateStream compression.
• Summary of parameter values in Target Analzyer.
• Ability to load scope configuration items from a text file.
• Ability to import and export Burp Proxy's CA certificate.
• Fine-grained options for configuring SSL protocols and ciphers.
• Auto-selection of compatible SSL parameters on negotiation failure.
• Optional re-enabling of SSL algorithms blocked by Java 7 security policy.
• Per-host SSL certificates in invisible proxy mode, via the server_name extension in the Client Hello message.
• Workaround to prevent OS X from deleting Burp's temporary files when Burp is left running for long periods.
• Fast-reload of extensions (via ctrl+click) to facilitate development.
• Several new Burp Extender APIs.
• Command-line license activation for use in headless mode.
• Numerous important bugfixes.

All of these changes were directly requested by Burp users, via the user forum, email, or Twitter. Now, we need more meat for the feature request sausage machine, so we encourage everyone who uses Burp to send us your own wish list.
Our queue of items for development uses a highly complex algorithm based on a fusion of FIFO, LIFO and can-we-be-arsed technologies. If you've asked for something before and it hasn't appeared yet, please ask us again. Even if you think something is too trivial or too complex, ask us anyway. The more people who request something, the more likely it will be to happen.

Burp is only as awesome as it is today because of feedback from our users. Thanks to everyone for your help!
 

New video tutorials

We've started a new series of video tutorials about Burp Suite. We're starting off with some beginner topics to help new users get started. We'll be adding to the series over the coming weeks, and will move onto some more advanced subjects.

• Burp Suite video tutorials

Sample Burp Suite extension: Intruder payloads

This example shows how you can use an extension to:

• Generate custom Intruder payloads
• Apply custom processing to Intruder payloads (including built-in ones)

When an extension registers itself as an Intruder payload provider, this will be available within the Intruder UI for the user to select as the payload source for an attack. When an extension registers itself as a payload processor, the user can create a payload processing rule and select the extension's processor as the rule's action.

When Burp calls out to a payload provider to generate a payload, it passes the base value of the payload position as a parameter. This allows you to create attacks in which a whole block of serialized data is marked as the payload position, and your extension places payloads into suitable locations within that data, and re-serializes the data to create a valid request. Hence, you can use Intruder's powerful attack engine to automatically manipulate input deep within complex data structures.

This example is artificially simple, and generates two payloads: one to identify basic XSS, and one to trigger the ficititious vulnerability that was used in the previous custom scanner check example. It then uses a custom payload processor to reconstruct the serialized data structure around the custom payload.

Download the Intruder payloads extension. The download includes source code and the compiled JAR file for Java. It also includes an ASP.NET page that extends the serialization example to add some fictitious bugs so that you can test the custom payloads, and see that the two vulnerabilities are triggered. After loading the extension, you'll need to select the custom payloads as your Intruder payloads type, and add a payload processing rule that invokes the extension-provided processor. Note: the sample ASP.NET page uses the JavaScript btoa() function to perform Base64-encoding on the client side. This function is not supported by Internet Explorer, but works on most other browsers.

Sample Burp Suite extension: custom scanner checks

In the previous example, we saw how an extension could be used to provide custom insertion points for use by Burp Scanner, enabling you to run the Scanner's built-in checks against entry points within serialized data or other formats that Burp does not natively support. In this example, we'll see how an extension can be used to futher extend the Scanner's behavior, by providing custom checks for passive and active scanning.

Custom scan checks are tightly integrated within Burp's scanning engine, and are invoked at the relevant stage for each base request and insertion point that the user sends for scanning. They can perform arbitrary processing, issue their own requests (when actively scanning), and report their own custom scan issues.

For the sake of this example, we've updated the demo serialized input application to contain two fictitious vulnerabilities that our extension can check for:

• An information leakage vulnerability where a content management system is copying sensitive data into some application responses.
• An input vulnerability where submitting the pipe character results in a distinctive error message, indicating an exploitable condition.

The sample extension demonstrates the following techniques:

• Registering a custom scanner check.
• Performing passive and active scanning when initiated by the user.
• Using the Burp-provided IScannerInsertionPoint to construct requests for active scanning using specified payloads, without needing to understand how the insertion point works.
• Using a Burp helper method to search responses for relevant match strings.
• Highlighting relevant portions of requests and responses, in line with Burp's natively-generated scan issues.
• Synchronously reporting custom scan issues in response to the relevant checks.
• Guiding Burp on when to consolidate duplicated issues at the same URL (e.g., when the user has scanned the same item multiple times).

If you want to run this extension, you'll need to use the updated ASP.NET page, and also install the previous custom scan insertion points example, so that the active scan payload is inserted correctly into the serialized request.

Download the custom scanner checks extension. The download includes Java source code and the compiled JAR file. It also includes an ASP.NET page that extends the serialization example to add some fictitious bugs so that you can test the custom scanner check and see that the issues are reported. Note: the sample ASP.NET page uses the JavaScript btoa() function to perform Base64-encoding on the client side. This function is not supported by Internet Explorer, but works on most other browsers.

Sample Burp Suite extension: custom scan insertion points

In the previous example, we saw how a simple Burp extension could be used to render and edit a custom message data format, within the Burp UI. For the purpose of demonstrating this capability, we used a trivial serialization format, in which user-supplied input is Base64-encoded within a request parameter value.

That example contained a rather obvious XSS vulnerability: the raw input contained within the serialized data is echoed unfiltered in the application's response. But although this type of bug might be obvious to a human, automated scanners will not (in general) identify any kinds of input-based vulnerabilities in cases where the raw input needs to be embedded within an unsupported serialization format. Since the scanner does not understand the format, it has no means of submitting its usual scan payloads in the way that is needed for the application to unpack and process the payloads and trigger any bugs. This means that in this situation, equipped only with the previous example of a custom editor tab extension, you would be restricted to manual testing for input-based bugs, which is a tedious and time-consuming process.

The new extensibility API lets you tackle this problem by registering your extension as a provider of custom scanner insertion points. For each actively scanned request, Burp will call out to your extension, and ask it to provide any custom insertion points that are applicable to the request. Each insertion point that you provide is responsible for the job of constructing validly-formed requests for specific scan payloads. This lets your extension work with any data format, and embed the scanner's payloads within the request in the correct way.

Here, we can see Burp reporting the XSS vulnerability, which it has found via the custom "Base64-wrapped input" insertion point:

Here is the request that Burp made, and which was generated for Burp by our custom insertion point:

Here, via our custom message editor tab, is the literal scan payload that is embedded in the request:

So, with a few lines of extension code, we have taught Burp Scanner how to work with the unsupported serialization format. All of Burp's built-in scan checks can now place their payloads correctly into the application's requests, and bugs like this can be quickly found.

Download the custom scan insertion points extension. The download includes source code for Java and Python, and the compiled JAR file for Java. It also includes an ASP.NET page that implements the serialization format on the client and server side, so that you can send serialized data from your browser, send the request for active scanning within Burp, and find the vulnerability. Note: the sample ASP.NET page uses the JavaScript btoa() function to perform Base64-encoding on the client side. This function is not supported by Internet Explorer, but works on most other browsers.

Sample Burp Suite extension: custom editor tab

This extension demonstrates how you can extend Burp's own HTTP message editor to handle the display and editing of unsupported data formats. This capability can let you handle custom serialization implemented by specific applications, or any other data format that Burp does not natively support.

In the past, some extensions have handled unsupported serialization formats by hooking into Burp's HTTP stack, and modifying incoming and outgoing messages, in order to unpack and repack the serialized data. Although this approach can work, it is quite restricted in the type of data it can handle. And it is also inelegant: it would be preferable to customize Burp to understand the custom format itself, rather than tampering with the integrity of HTTP messages.

The new extensibility API lets you add custom tabs to Burp's HTTP message editor. When a message is about to be displayed, Burp will ask the tab whether it can handle the message. If so, the custom tab will be shown in the editor, and can support rendering and editing of the message within its own UI:

The sample extension uses an artificially simple serialization format: the serialized data is simply Base64-encoded within a request parameter. This example was chosen so as to keep the code that handles the serialization as simple as possible. But the format itself isn't the point: what matters is that you can now easily extend Burp to understand any format that you may encounter in a test.

As well as the new API for adding message editor tabs, this example also makes use of Burp's new helper methods, to carry out common tasks such as parsing and updating request parameters, encoding and decoding data in different formats, and conversion of data between String and byte forms.

Download the custom editor tab extension. The download includes source code for Java and Python, and the compiled JAR file for Java. It also includes an ASP.NET page that implements the serialization format on the client and server side, so that you can send serialized data from your browser, edit this on the fly within Burp, and see the effect in the server's response. Note: the sample ASP.NET page uses the JavaScript btoa() function to perform Base64-encoding on the client side. This function is not supported by Internet Explorer, but works on most other browsers.

[Really astute testers might spot a deliberate vulnerability in the sample ASP.NET page. More on that soon.]