sniper - This uses a single set of payloads. It targets each position in turn, and inserts each payload into that position in turn. Positions which are not targeted during a given request are not affected - the position markers are removed and any text which appears between them in the template remains unchanged. This attack type is useful for testing a number of data fields individually for a common vulnerability (e.g. cross-site scripting). The total number of requests generated in the attack is the product of the number of positions and the number of payloads in the payload set.

battering ram - This uses a single set of payloads. It iterates through the payloads, and inserts the same payload into all of the defined positions at once. This attack type is useful where an attack requires the same input to be inserted in multiple places within the HTTP request (e.g. a username within the Cookie header and within the message body). The total number of requests generated in the attack is the number of payloads in the payload set.

pitchfork - This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through all payload sets simultaneously, and inserts one payload into each defined position. I.e., the first request will insert the first payload from payload set 1 into position 1 and the first payload from payload set 2 into position 2; the second request will insert the second payload from payload set 1 into position 1 and the second payload from payload set 2 into position 2, etc. This attack type is useful where an attack requires different but related input to be inserted in multiple places within the HTTP request (e.g. a username in one data field, and a known ID number corresponding to that username in another data field). The total number of requests generated by the attack is the number of payloads in the smallest payload set.

cluster bomb - This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through each payload set in turn, so that all permutations of payload combinations are tested. I.e., if there are two payload positions, the attack will place the first payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2; it will then place the second payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2. This attack type is useful where an attack requires different and unrelated input to be inserted in multiple places within the HTTP request (e.g. a username in one parameter, and an unknown password in another parameter). The total number of requests generated by the attack is the product of the number of payloads in all defined payload sets - this may be extremely large.

I am getting seriously hyped about this next release of Burp Pro.

By creating multiple rules with different scopes and actions, you can define a hierarchy of behaviour that Burp will apply to different applications and functions. For example, on a particular test you could define the following rules:

• For all requests, add cookies from Burp's cookie jar.

• For requests to a specific domain, validate that the current session with that application is still active, and if not, run a macro to log back in to the application, and update the cookie jar with the resulting session token.

• For requests to a specific URL containing the __csrftoken parameter, first run a macro to obtain a valid __csrftoken value, and use this when making the request.

This is phenomenally cool stuff that's getting added in 1.4...

One exciting new feature to help with access control testing is the facility to compare two site maps and highlight differences. This feature can be used in various ways to help find different types of access control vulnerabilities, and identify which areas of a large application warrant close manual inspection. Some typical use-cases for this functionality are as follows:

• You can map the application using accounts with different privilege levels, and compare the results to identify functionality that is visible to one user but not the other.

• You can map the application using a high-privileged account, and then re-request the entire site map using a low-privileged account, to identify whether access to privileged functions is properly controlled.

• You can map the application using two different accounts of the same type, to identify cases where user-specific identifiers are used to access sensitive resources, and determine whether per-user data is properly segregated.

You can access the new feature using the context menu on the main site map:

A very welcome new feature. I can't wait for the beta to drop for pro users.

Any HTTP response within Burp can now be rendered in your browser, to avoid the limitations of Burp's built-in HTML renderer. This feature is accessed by selecting any item with a response, and choosing the "show in browser" item from the context menu. Burp then gives you a unique URL which you can paste into your browser (configured to use the current instance of Burp as its proxy), to render the response. The resulting browser request is served by Burp with the exact response that you selected (the request is not forwarded to the original web server), and yet the response is processed by the browser in the context of the originally requested URL. Hence, relative links within the response will be handled properly by your browser. As a result, your browser may make additional requests (for images, CSS, etc.) in the course of rendering the response - these will be handled by Burp in the usual way.

The function to save Burp's state now includes an option to include only in-scope items. When working on a client engagement, this enables you to save only relevant items for archiving or sharing with colleagues. The new option is available in the save state wizard, in the automatic backup feature, and in scheduled tasks that save state.

IBurpExtenderCallbacks now includes the following methods for loading and saving configuration:

java.util.Map saveConfig()

void loadConfig(java.util.Map config)

Configuration information is handled as a map of name/value pairs. Any settings not specified in the Map will be restored to their default values. To selectively update only some settings and leave the rest unchanged, you should first call saveConfig to obtain Burp's current configuration, modify the relevant items in the Map, and then call loadConfig with the same Map.

IBurpExtenderCallbacks now includes the following method for adding arbitrary items to Burp's site map:

void addToSiteMap(IHttpRequestResponse item)

This method allows extensions to write custom interfaces to import the output from other tools.

IHttpRequestResponse now includes the following methods for accessing user-annotated comments in items belonging to Burp tools that support comments:

java.lang.String getComment()

void setComment(java.lang.String comment)

Burp Intruder now includes a built-in payload list containing User-Agent strings for numerous browsers. This can be used for testing whether applications return different content to different mobile devices, etc.

The Suite-wide options now include a default-off option to enable all supported cipher suites during SSL negotiation. This option is not normally necessary but may be useful when attempting to connect to unusually configured SSL stacks.

This release fixes another source of UI instability when running on Mac. Soon, Burp is going to be so stable on this platform that it will prevent OSX itself from crashing.