Burp Suite, the leading toolkit for web application security testing

Burp Suite Professional - Release Notes

Tuesday, April 15, 2014


This is the final v1.6 release.

Burp Suite Free Edition contains significant new features added since v1.5, including:
  • Support for WebSockets messages.
  • Support for PKCS#11 client SSL certificates contained in smart cards and physical tokens.
  • A new Extender tool, allowing dynamic loading and unloading of multiple extensions.
  • A new powerful extensibility API, enabling extensions to customize Burp's behavior in much more powerful ways.
  • Support for extensions written in Python and Ruby.
  • A new BApp Store feature, allowing quick and easy installation of extensions written by other Burp users.
  • An option to resolve DNS queries over a configured SOCKS proxy, allowing access to TOR hidden services.
  • Generation of CSRF PoC attacks using a new cross-domain XHR technique.
  • New options for SSL configuration, to help work around common problems.
  • Optional unpacking of compressed request bodies in the Proxy.
  • Support for .NET DeflateStream compression.
  • New and improved types of Intruder payloads.
  • New Proxy interception rules.
  • New Proxy match/replace rules.
  • Improved layout options in the Repeater UI.
  • An SSL pass-through feature, to prevent Burp from breaking the SSL tunnel for specified domains.
  • Support for the Firefox Plug-n-hack extension.
  • An option to copy a selected request as a curl command.
Burp Suite Professional contains a number of bugfixes and tweaks, added since the last beta version, including:
  • An occasional bug causing misplaced highlights on payloads in Scanner issues has been fixed.
  • A bug in which restoring default settings for the Extender tool didn't unload any currently running extensions has been fixed.
  • A display bug affecting the rendering of binary content (such as images) in the raw view of the HTTP message editor has been fixed.
  • A bug which prevented the automatic backup on exit feature from functioning in headless mode has been fixed.
  • In previous versions, Burp stored its preferences in separate locations for each major version. This caused persisted settings to be lost on upgrading to a new major version. This behavior has been modified, and from v1.6 onwards major versions will store their preferences in the same location. As a workaround to preserve settings from earlier releases, Pro users can launch the earlier release, save a state file containing their preferences, then launch the new release and load the state file.
Work is already underway on some exciting new features that will be arriving post v1.6 ...

Free edition
MD5: 6f2c0ff4e3cab35bb49312ce88e1a690
SHA256: 21cfdd2d2f682997648f3877bca239bde358f8ce5a2a9304fd1de72fc68a3312

Pro edition
MD5: 8d56e783e79f615feefd3717322d61dd
SHA256: d81a765df2eb2fc33f91cdbf2669264204a9acf2ed7e43187ff7632015ffa89b

Thursday, April 3, 2014


This release fixes a number of bugs:
  • A bug in v1.6beta that caused some saved state files to be corrupted has been fixed. The majority of problematic state files that were generated with the previous version should be loadable in this release.
  • A bug in the HTTP message viewer which caused parts of a message not to be displayed in certain situations has been fixed.
  • A bug arising on certain platforms (e.g. some OS X retina machines), in which the HTTP message viewer displays the cursor in the wrong position, has been addressed. Since this was a platform-specific problem, and we weren't able to reproduce the bug on all reported configurations, we welcome feedback as to whether any further instances of this problem are remaining.
  • Problems affecting Proxy SSL negotiation on Java 8 have been addressed. Burp is not yet officially supported on this platform, pending further testing, but we welcome feedback about any further problems that arise on Java 8.
  • Some XSS edge cases relating to URL-encoding of specific payload characters, which were being missed by Burp, are now detected properly.
  • A bug in the Intruder custom iterator payload type, which caused it not to generate the expected payloads in certain conditions, has been fixed.
  • The opt-out checkbox for reporting of anonymous performance feedback, which previously appeared only on an options panel, has been added to the EULA acceptance dialog.
MD5: 2bae268d34ead1cf4cecc8a31840a427
SHA256: 8d3c71c4044f039e87f0838335e698d29d68e00dfe76c3a987eec93f138456d0

Tuesday, March 4, 2014


This release introduces the BApp Store, a repository of Burp extensions that have been written by users of Burp Suite, to extend its capabilities:

You can install BApps with one click from within Burp, and you can also download them from the BApp Store web site for manual installation on machines without Internet access. We've assembled an initial list of extensions and will hopefully be adding more soon.

The handling of URL-encoding of parameters within session handling macros has been rationalized, to make Burp "just do" the right thing in nearly every case, without the need for any special configuration by the user. Previously, there was a per-parameter configuration option whether to URL-encode its value. Since Burp actually knows the context in a response from which a parameter's value is being derived, and the context in a subsequent request into which it is being placed, Burp can automatically take care of the encoding in exactly the cases where it is needed.

The exception to this, where some manual configuration is still required, is where you have configured a custom parameter location within a response. Since this is a custom location, you need to tell Burp whether or not the raw extracted value is already URL-encoded, and Burp will handle it correctly when using its value in subsequent requests.

A bug that was introduced in v1.5.21, affecting Proxy SSL negotiation in cases where the client has only specified an IP address, has been fixed. The previous behavior, where Burp fetches the authentic SSL certificate from the destination host and forges a copy signed by its own CA certificate, has been restored. This technique is necessary to support Android clients, which only send a target's IP address in the CONNECT request that precedes the SSL negotiation.

This is officially a beta release, and when the final version is released, relevant changes since v1.5 will be ported into a new release of Burp Suite Free Edition.

MD5: 06c8148609ff9f9ad9f92937c2047425
SHA256: 7f4b26e428742b00a8464150ef82a2c94720ef9b62ea513435f41bf4dfb39265

Thursday, January 30, 2014


This release adds support for WebSockets to the Proxy tool. You can now view, intercept and modify WebSockets messages in the same way as regular HTTP messages:

There is a new Proxy history tab for WebSockets messages, with the same capabilities as the HTTP history (filter, sort, search, etc.):

You can configure whether incoming and outgoing WebSockets messages are intercepted at Proxy / Options / Intercept WebSockets Messages.

The Scanner's support for nested insertion points, which was introduced in the previous release, has been updated:
  • Nested data in URL-encoded query string format is now recognized, and insertion points are created for each parameter value within the nested data. This is only done if the nested query string contains at least two parameters, so as to avoid false positive in common cases where a parameter value happens to contain the = character.
  • Highlighting of relevant syntax in reported Scanner issues is now fully precise within nested insertion points, and picks out the exact item of input that Burp modified in order to identify the issue.
The Scanner reporting function now has an option to embed report images inline within the generated HTML. This works on all recent browsers, but you can revert to the old behavior (of images stored in a subdirectory) if you prefer.

There is a new function to report anonymous feedback about Burp's performance. This will help us improve Burp by obtaining technical information about problems within Burp. The feedback does not identify the user, but you can turn this function off at Options / Misc / Performance Feedback.

Various bugs have been fixed.

MD5: b80c61d45054e483870f75fff35d0c56
SHA256: 52903a758d6714aedb90a45f58a477df40288be76ae0f1961510c8755a4ef903

Friday, November 29, 2013


This release adds support for nested insertion points to the Scanner.

Nested insertion points are used when an insertion point's base value contains data in a recognized format. For example, a URL parameter might contain Base64-encoded data, and the decoded value might in turn contain JSON or XML data. With the option to use nested insertion points enabled, Burp will create suitable insertion points for each separate item of input at each level of nesting.

Below are some examples of Burp's new capabilities in scanning nested insertion points, running against some targets in our lab.

SQL injection into a Base64-encoded value within a JSON value within a URL parameter:

SQL injection into a JSON value within XML within a URL parameter:

SQL injection into XML within a JSON value within a URL parameter:

XSS in a JSON value within a Base64-encoded URL parameter:

XSS in a JSON value within XML within a URL parameter:

XSS in an XML value within JSON within a URL parameter

You get the idea. There is no limit to how deep Burp can go. If it recognizes the data format of the base value of any insertion point, Burp will look inside that data for nested values that should be tested.

The option to include nested insertion points is on by default, and using this option imposes no overhead when scanning requests containing only conventional parameters. However, it enables Burp to reach much more of the attack surface of today's complex applications where data is encapsulated within different formats.

MD5: 08396c07da2f11a9f17212c3e4299b07
SHA256: d4e547b8d1bd63d2b65b605239c9c03058080deed14e3bfe9ebe538601baf537

Monday, November 25, 2013


This release contains a number of enhancements to the Scanner tool.

Active Scanner optimization

There is a new set of Scanner options which let you control the behavior of the active scanning logic in relation to scan speed and accuracy:

  • Scan speed - This option determines how thorough certain scan checks will be when checking for vulnerabilities. The "Fast" setting makes fewer requests, and checks for fewer derivations of some vulnerabilities. The "Thorough" setting makes many more requests and checks for more derivative types of vulnerabilities. The "Normal" setting is mid-way between the two, and represents a suitable trade-off between speed and thoroughness for many applications.
  • Scan accuracy - This option determines the amount of evidence that the Scanner will require before reporting certain types of vulnerabilities. Some issues can only be detected using "blind" techniques, in which Burp infers the probable existence of a vulnerability based on some observed behavior, such as a time delay or a differential response. Because these observed behaviors can occur anyway, in the absence of the associated vulnerability, the techniques are inherently more prone to false positives than other techniques, such as the observation of error messages. To attempt to reduce false positives, Burp repeats certain tests a number of times when a putative issue is inferred, to try and establish a reliable correlation between submitted inputs and observed behaviors. The accuracy option is used to control how many times Burp will retry these tests. The "Minimize false negatives" setting performs fewer retries, and so is more likely to report false positive issues, but is also less likely to miss genuine issues due to inconsistent application behavior. The "Minimize false positives" setting performs many more retries, and so is less likely to report false positive issues, but may as a result wrongly miss some genuine issues, because some of the retry requests might just happen to fail to return the result being tested for. The "Normal" setting is mid-way between the two, and represents a suitable trade-off between false positive and false negative issues for many applications.

Payload encoding

Burp's internal logic handling the placement of scan payloads into insertion points has been reworked to resolve some occasional problems. In previous versions, Burp applied incorrect encoding to certain payloads in certain insertion points - for example, wrongly URL-encoding some characters in locations where URL-encoding is not necessary. This caused Burp to miss some edge case vulnerabilities in applications where Burp's non-standard encoding was not tolerated.

The improved handling of encoding within insertion points paves the way for some further enhancements to the Scanner's capabilities, and the next Scanner update will include more more powerful insertion point types, enabling Burp to find more vulnerabilities in today's complex applications.


In order to fix the erroneous handling of encoding within some insertion points, Burp's contract with extensions in relation to customizing the Scanner has unfortunately needed to change. We apologize for this, however the previous contract was in any case not consistent, and left extensions with impossible responsibilities in some situations.

Previously, Burp-provided insertion points did not do any payload encoding, and extension-provided checks were required to submit suitably encoded payloads based on the insertion point type (for example, URL-encoding spaces in URL parameters, HTML-encoding tag brackets in XML parameters, etc.). In some cases, it wasn't actually possible for extensions to fully determine the encoding that was needed. Further, the old approach risked leaving extensions unable to deal with new insertion point types that we plan to introduce to Burp. In the new contract, Burp-provided insertion points will automatically carry out suitable encoding of payloads, and so extension-provided checks should submit raw payloads.

Regarding extension-provided insertion points, the contract has always been that Burp will submit raw payloads (although this contract may have been inconsistently honored by Burp due to the payload encoding issues described in the previous section). This contract remains in place and is now strictly followed by Burp, so extension-provided insertion points need to handle encoding of relevant payload characters based on the nature of the insertion point.

This change in the contract brings consistency to the responsibility of Burp- and extension-provided insertion points, and enables both Burp and extensions to function in a less coupled, more future-proof way.

Note that in a few rare cases, an extension-provided check may require complete control over how its payloads are encoded within insertion points - for example, in order to violate protocol-level rules for the proper representation of data in different contexts. In this situation, the extension should also create its own custom insertion points, in order to gain full control over the end-to-end payload handling process.

In addition to the previous changes, as an aid to extension authors, Burp's implementation of IScannerInsertionPoint.buildRequest() has been modified so that Burp always fixes the Content-Length header when the message body length has changed. Extension-provided implementations of this method are not obliged to do this.

XML reporting

The XML-based reporting of Scanner issues now includes the following details:
  • method attribute on request elements, indicating the HTTP method used in the request.
  • A collection of issueDetailItem elements on some issue types, such as disclosure of email or IP addresses, containing the individual information items in machine-readable form.

User interface

In Scanner options, the panels with checkboxes to enable specific active and passive checks now have "Select all" and "Select none" buttons.

The Scanner reporting wizard, the panel with checkboxes to select specific types of issue to report now has "Select all" and "Select none" buttons.

MD5: 2219c127beef63a7c687dad1ba723e8c
SHA256: 432fe093ac09839bc4365e34015a8a7bdbd0583e26099582ca66b627e66baf98

Thursday, November 7, 2013


This release includes a number of updates to the Scanner tool:
  • Several checks for new types of vulnerabilities have been added.
  • Various existing checks have been enhanced to improve their accuracy in avoiding false negatives and positives.
  • A number of bugs have been fixed.
The new types of issues that Burp can now report are:
  • Remote file inclusion
  • Recursive XML entity expansion
  • Response dependent on X-Forwarded-For header in request
  • "Long" redirection responses
  • Base64-encoded data within request parameters
MD5: b31353680bd08568fdc0fce15fedec13
SHA256 : 40b917c1a9034ec0c0698968c2bbbcde2e07a842043015843a30fcdd11f31b5d

Tuesday, September 17, 2013


This release includes a number of enhancements and bugfixes:
  • There is a new "copy as curl command" function on context menus. This function constructs a curl command that generates the selected request, and copies the command to the clipboard.
  • The Extender tool has a new option to specify a folder from which Burp will load library JAR files for use by Java extensions.
  • The IBurpExtenderCallbacks interface has several new methods:
    • Methods to list and remove extension-provided resources such as event listeners, resource factories, etc.
    • Methods to print a line of output to the extension's stdout or stderr streams.
  • The numbers payload generator in Intruder has been enhanced to cope with numbers of arbitrary size and precision, and is no longer subject to the constraints of Java's native integer or floating point arithmetic. It is possible configure and launch attacks that will result in arbitrarily many payloads. If the number of payloads exceeds 2^31 then Burp will report the number as "unknown" but the attack will still proceed in the expected way (even though actually completing the attack is not feasible).
  • There is a new hotkeyable action to forward the request currently showing in the Proxy intercept view and force interception of the response. This action is not assigned a hotkey by default.
  • The save and restore state functions can now include the configuration options for the Extender tool.
  • The extensibility API to retrieve the contents of the site map now auto-generates GET requests for items in the site map that have not yet been requested.
  • A bug in the session handling action to update the value of a named parameter, where multiple parameters with the same name were not updated, has been fixed.
  • A bug in Intruder that caused some valid custom iterator configurations to fail has been fixed.
  • A bug in the invocation of extension-provided custom Scanner checks, where an exception thrown by an extension could cause Burp's scanning thread to die, has been fixed.
  • A bug in the CSRF PoC generator where pure GET requests are not properly handled has been fixed. (Of course, a pure GET request is itself deliverable cross-domain using only its own URL, but Burp now gives the option of delivering the request via a form submission if required.)
MD5: 2b9a66b72e0162229103d4d57548384c
SHA256: 4a99433e77eb004f2b6a36d94256020ea379e4a65c38d3b866a3e17c46bc6d7b

Thursday, September 5, 2013


This release fixes two bugs that were introduced in the v1.5.15 release:
  • A bug that caused some request headers to be lost when certain edits were made to request parameters has been fixed.
  • A bug where in-browser error messages contained relative links to in-browser UI functionality, causing broken links where the error page is returned to a request for an external domain, has been fixed. 
MD5: d73b8f5a072bd671328f1acdb9c83727
SHA256: 237559ff92a75460763737f1d849d232a3412c83e43cd8aa80bb33ea2f8e2d29

Tuesday, September 3, 2013


This release includes a large number of updates to the Proxy tool.

SSL Pass Through

You can now specify destination web servers for which Burp will directly pass through SSL connections. Passing through SSL can be useful in cases where it is not straightforward to eliminate SSL errors on the client - for example, in mobile applications that perform SSL certificate pinning. If the application accesses multiple domains, or uses a mix of HTTP and HTTPS connections, then passing through SSL connections to specific problematic hosts still enables you to work on other traffic using Burp in the normal way.

If the option to automatically add entries on client SSL negotiation failure is enabled, then Burp will detect when the client fails an SSL negotiation (for example, due to not recognizing Burp's CA certificate), and will automatically add the relevant server to the SSL pass through list.

Startup Interception State

There is a new option to configure whether proxy interception should be enabled when Burp is started up. You can choose to always enable interception, always disable interception, or to restore the setting from when Burp was last closed.

Highlighting Unhidden Fields

When Burp is configured to automatically unhide hidden fields in responses, there is a new sub-option to prominently highlight unhidden fields on-screen, for easy identification:

Fix Newlines In Edited Requests

There is a new option to automatically fix missing or superfluous new lines at the end of requests that have been edited in the intercept view. If an edited request does not contain a blank line following the headers, Burp will add this. If an edited request with a body containing URL-encoded parameters contains any newline characters at the end of the body, Burp will remove these.

This new option, which is off by default, can be useful to correct mistakes made while manually editing requests in the interception view, to avoid issuing invalid requests to the server.

New Interception Rules

You can now configure interception rules for requests and responses based specifically on the names and values of cookies. You can configure rules for responses based on the MIME type and on whether the request was annotated (commented or highlighted) by the user.

New Match/Replace Rules

Various updates have been made to the match/replace functionality:
  • You can define rules based on parameter names and values.
  • You can configure a rule to operate only on the first line of requests, for making quick changes to the URL or request method.
  • You can optionally use literal or regular expressions in match rules.
  • You can add comments to rules to describe their purpose. This facilitates quick toggling of individual rules without needing to read them to understand what they are doing.
  • Various new default rules have been added for performing common tasks.
  • The documentation has been updated to describe how you can use regular expressions to match multi-line regions of message bodies, and how you can use regex groups in back-references and replacement strings.

Editing Target Server in Intercept View

You can now manually edit the target server to which an intercepted request will be sent, by clicking on the server caption or the button next to it.

Updated In-Browser Burp UI

Burp's in-browser UI has been updated in various ways:
  • There are more readable and informative messages when a request causes a problem.
  • Invalid client requests are reproduced in full in the error message, to assist debugging.
  • The interface is now available both at http://burp (when you have configured your browser to use Burp as its proxy) and at the URL of your Burp listener (for example,, even if your browser is not configured to use Burp).

Support for Firefox Plug-n-hack Plugin

Burp now supports the new Firefox plug-n-hack plugin. This enables faster configuration of the browser to work with Burp, by automatically configuring the browser to use Burp as its proxy, and installing Burp's CA certificate in the browser. If you are using Firefox and have installed the plug-n-hack plugin, you can configure your browser to use Burp by visiting the URL of your Burp listener (by default, and following the "Plug-n-hack" link.


Quick Navigation of History In Repeater

The back/forward buttons for navigating the Repeater history now have drop-down lists showing numbered nearby items in the history, to enable quick navigation to a required item.

MD5: 72fa775fff28cee8f53e30b853f7231e
SHA-256: 0b0a56960278e48aa6cc336e2e34dc12d86926e6a8f60ba4403ae633af5fcde1

User Forum

Get help from other users, at the Burp Suite User Forum:

Visit the forum ›

Copyright 2014 PortSwigger Ltd. All rights reserved.