Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility

Wednesday, December 9, 2015


This release introduces a brand new tool: Burp Clickbandit.

Burp Clickbandit is a tool for generating clickjacking attacks. When you have found a web page that may be vulnerable to clickjacking, you can use Burp Clickbandit to create an attack, to confirm that the vulnerability can be successfully exploited.

Burp Clickbandit is built in pure JavaScript, and is easy to use. In Burp, go to the Burp menu and choose "Burp Clickbandit". Copy the script to your clipboard, and paste it into the web developer console in your browser. It works on all modern browsers except for Microsoft IE and Edge.

For more details about how Burp Clickbandit works and how to use it, see the blog post.

This release also adds the following enhancements:
  • There is a new option in the Proxy to set the "Connection: close" header on incoming requests. Setting this header in requests can speed up the processing of the resulting responses from some target servers. The new option is on by default.
  • When generating the CA certificate used by the Proxy, Burp now uses a 2048-bit key if that is supported by the platform, and fails over to a 1024-bit key if not. Some modern clients are rejecting certificates that use a key length shorter than 2048 bits. If you encounter this problem, you can tell Burp to generate a new CA certificate at Proxy / Options / Proxy Listeners / Regenerate CA certificate, and you will need to install the regenerated certificate in your browser in the normal way.
Burp Suite Professional:
MD5: 60d496721e75bc7f73106991f68514ff
SHA256: 45563deb20309c9b4b79b771c76bc55631cdd030ae9c6c72b359cfb1d156e42d

Burp Suite Free Edition:
MD5: ea4e6bac280f854a2125e631a6c82a1c
SHA256: 7a27e95d86dc38cf261485c2050851715181cdce6b8cb0052239c5970fa94543

Wednesday, December 2, 2015


This release enhances Burp Scanner to report issues based on deferred interactions with the Burp Collaborator server.

Asynchronous server-side injection vulnerabilities are normally invisible in an application's responses, and completely elude conventional scanning techniques. To detect invisible vulnerabilities, Burp Scanner uses payloads that cause the application to make some kind of network connection to the Collaborator server. When an interaction with the Collaborator server is observed, this demonstrates that the payload was successful and a vulnerability is present.

In this release, invisible vulnerabilities are reported even when the interaction occurs after Burp has finished scanning the relevant item. After scanning has completed, Burp continues polling the Collaborator server in the background, and retrospectively reports issues when deferred interactions occur. This cutting-edge capability allows Burp to report all kinds of serious issues that are otherwise impossible to detect, for example:
  • Blind second-order SQL injection, where a payload gets stored and later used in an unsafe SQL query, with no behavioral evidence in the application's responses.
  • OS command injection in an overnight batch job that passes stored user input into shell commands in an unsafe way.
  • Asynchronous back-end SOAP/XML injection where user input is stored and later embedded in an XML-based message in an unsafe way.
Each Burp session uses a unique identifier to track Collaborator interactions, and this can optionally be included in the Burp state file when saving your work. This means that you can later reload a state file containing completed scans, and observe any asynchronous Collaborator interactions that have occurred since you finished the original scanning. On reloading the state file, Burp will poll the Collaborator server and report issues based on any new interactions that have occurred for that Burp session. 

Burp polls the Collaborator for asynchronous interactions every few minutes. When an asynchronous interaction is detected, Burp reports the issue without making any in-band requests to the target application. This means that you can safely revisit completed scans to pick up any asynchronous vulnerabilities even if the time window for testing is over. So imagine this: you finish testing on Friday without any decent issues; you load the Burp state file on Monday to start writing your report, and discover that one of your payloads has detected a command injection vulnerability in a shell script that runs over the weekend. Pretty cool?

[In fact, Burp began optionally saving Collaborator identifiers in state files starting with version 1.6.29. So if you have a state file from a test that was carried out with Burp 1.6.29 or later, you can reload it into the latest release to see if any deferred Collaborator interactions have occurred since you completed your testing.]

People are accustomed to seeing Burp report vulnerabilities during scanning, and not afterwards. To help users identify when deferred Collaborator interactions have occurred, a number of related useful features have been added:
  • The Scanner has a new "Issue activity" tab that contains a sequential record of when issues are created or updated. You can monitor this tab to view everything that is reported by the Scanner in time order, including detection of deferred Collaborator interactions.
  • When an issue is reported based on a deferred Collaborator interaction, the issue detail indicates the approximate elapsed time between the relevant scan completing and the interaction occurring.
  • The active scan queue has two new columns indicating the times that scanning started and ended for each item. This can help correlate the timings of Scanner activity and observed Collaborator interactions.
Note: The reporting of elapsed time between scan and interaction depends on some new capabilities in the Collaborator server. It is recommended that users who have deployed a private Collaborator server should upgrade to the latest Burp release, to gain the benefit of this feature.

In addition, some other updates have been made:
  • The BlazeDS library used for analyzing AMF messages has been updated to the latest version. This fixes some additional security vulnerabilities in BlazeDS's handling of malicious messages, which were found by the Burp research team. Since Burp version 1.6.29, Burp has disabled support for AMF messages by default, due to security concerns about the BlazeDS library. Any users who have enabled the option to support AMF messages should upgrade to the new release of Burp.
  • A problem comparing site maps from certain Burp state files has been fixed.
  • A problem installing some PKCS#11 certificates has been fixed.
  • All available command line arguments can now be listed by specifying the --help argument on the command line.
Burp Suite Professional
MD5: efdc0f3c468cbab6be3ae59c79e5bcdb
SHA256: 495f7ef5847836272678315a9d218b58534b11472cd041b5b954fb5926cdf79c

Burp Suite Free Edition
MD5: 425f0b339453c57e6628850381e36620
SHA256: 3e120b275e381840b549fcd9242950b1c74d4cc259b56b9422c11f00dfa26dc7

Tuesday, October 20, 2015


This release fixes a bug that was introduced in 1.6.29 in the handling of cookies in session handling rules. When a session handling rule attempts to update the values of multiple cookies within a single request, the bug caused this operation to fail in some situations, with the result that the request might be made out of session.

Burp Suite Professional:
MD5: e7e8cb9012cd2c81faf39ac877fb18e6
SHA256: 99baa396c9f7065791f1dc024919e25a63d7a9422ef502470620c41f859f9803

Burp Suite Free Edition:
MD5: e4a752d67ac23d0e1c103b694b42cb0b
SHA256: b048e08264de811a75e180aedf1fbf92bec9c3f8bc0016017e67a0a529b92768

Monday, October 19, 2015


This release updates Burp to include a security fix in the BlazeDS library that Burp uses for parsing AMF messages, and disables AMF support by default:
  • AMF messages can contain embedded XML content, and this is processed by the BlazeDS library when it parses AMF messages. BlazeDS has been found to contain an XXE vulnerability in its processing of XML embedded within AMF messages. In the context of Burp, the potential impact of the vulnerability is that a malicious target application could read the contents of files from the Burp user's computer, provided it knows the names of those files. A malicious application could perform this attack if it generates a suitable AMF message and the user browses via Burp to a response containing the AMF message. The latest version of BlazeDS contains a fix for the XXE vulnerability, and Burp has been updated to use the new version of the library. Thanks are due to David Klein from Context Information Security for drawing our attention to this issue.
  • It is well known that XML parsing is fraught with problems, as is demonstrated by Burp Scanner's XML checks. To reduce the impact of any further issues within BlazeDS, Burp has been updated so that by default it disables the AMF tab within the HTTP message editor, and disables AMF insertion points in the Scanner. Users can turn on these options if they are testing a trusted application that uses AMF messages. It is recommended that users do not enable AMF processing when accessing any untrusted application functionality or content.
Burp's cookie jar has been updated to support the cookie path attribute. The cookie jar is now able to track multiple cookies from the same domain with the same name, but which are scoped to different application paths. Burp's session handling rules now correctly update cookies in requests based on the path attribute.

The functions to save and restore state now include options for handling the unique identifier that Burp uses to track interactions with Burp Collaborator. Each Burp project/session generates a unique identifier that is used to track any Burp Collaborator interactions that are associated with the project. If two users share a state file, and each continues testing from that point, there is the potential for interference in Collaborator interactions, causing some Collaborator-based issues to be missed or incorrectly reported. When saving state, you can now choose whether to include the identifier within the state file, so that you or someone else can resume the testing later. When loading a state file that was saved using a different installation of Burp and which contains a Collaborator identifier, you can now choose whether to take full ownership of the project and receive details of any ongoing Collaborator interactions that are associated with the project. 

(Note that each fresh Burp project/session generates a new random Collaborator identifier, so there is no risk of permanent cross-talk between different Burp instances, regardless of the options chosen when sharing a specific state file.)

A bug affecting the importing of some custom CA certificates in PKCS#12 format has been fixed.

Burp Suite Professional:
MD5: bec6d3149193488adac77e2c45d4eafa
SHA256: d8706d3777ab710c6d7e069e9e6c953b515d0e4233ec4c531a310b89f62ae489

Burp Suite Free Edition:
MD5: c940c22451c53c5f7fda8cba2b151b2a
SHA256: 722b831cf899f23573e80f7ba856d1b9316de090be13e73ef0d026b877957687

Tuesday, October 6, 2015


This release adds the ability to annotate the active scan queue with comments and highlights, as is already possible in the Proxy history and Target site map:

Recently, we removed the ability to delete items from the active scan queue. This was done in preparation for some planned new capabilities that will enable the Scanner to retrospectively report issues for scan queue items that have finished scanning. For this capability to work, we needed to retain the full scan queue history. Some users have complained that they were using the deletion of items as part of their testing workflow. To address this issue, we have added the ability to apply comments and highlights to scan queue items. This provides an improved alternative to the previous workflow that these users were following.

A number of other changes have been made:
  • The performance of the Target site map when selecting tree branches containing very large numbers of scan issues has been dramatically improved.
  • The process of configuring Burp to use a PKCS#11 certificate has been improved. You can now manually select the required card slot during installation, swap cards at runtime, and reload configuration from state files more easily.
  • There is a new Scanner option to create an insertion point for the entire request body, for relevant content types. This currently applies to requests with XML or JSON content in the request body. This insertion point is enabled by default, and should allow detection of some additional edge-case vulnerabilities (e.g. server-side JavaScript injection where an entire request body containing JSON is passed to the JavaScript eval function).
  • The Scanner insertion point type that was previously called "REST-style URL parameters" has been replaced with two insertion point types, covering URL path folders and the final URL filename. The filename insertion point is enabled by default, while folder insertion points are still disabled. This change should improve Burp's detection of some issues in its default configuration, such as XSS through reflection of the full URL path excluding the query string.
  • A bug that caused occasional corruption of saved state files and prevented them from correctly reloading has been fixed.
  • Scanner issues that are reported by Burp extensions are now identified as such within the UI and scan reports. This was primarily done to reduce the number of support tickets relating to defects in the wording of extension-generated issues.
  • The temporary directories created by Burp should now not be world-readable on any platforms, to prevent direct access to Burp's temporary files from other users on a multi-user machine. Note that by default such users can in any case access a large quantity of sensitive data, and interfere with Burp's operation, via the default Proxy listener on Users are encouraged not to use Burp on a machine that is shared with untrusted users.
Burp Suite Professional:
MD5: 2e9dbfa9b582cab1684ae2750eb95c8e
SHA256: 2ce0e85e30a39c9d3e1a1dac363dd57af69f50a4d8c81c9dc870b7852c32edaa

Burp Suite Free Edition:
MD5: 058b1ce8993318498f8e25ee6d09853c
SHA256: a3cedb8a2223287328273d7a2b928adde69e33f08ade6934b0a968bfb05bfd8e

Friday, September 11, 2015


This release adds the ability to detect completely blind SQL injection by triggering interactions with Burp Collaborator.

Previously, Burp Scanner has used various evidence to detect SQL injection, including:
  • Error messages
  • Differential responses through injected Boolean conditions
  • Time delays
Each of these techniques involves sending payloads designed to trigger some kind of difference in the application's immediate response, whether in its actual contents or the time taken to receive it. In some situations, SQL injection conditions can exist that just cannot be found in this way, because there is no way to induce any difference in the application's immediate response.

Enter Burp Collaborator. Burp Scanner now sends payloads like:

'||(select extractvalue(xmltype(
'<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ 
<!ENTITY % glrvh SYSTEM "">%glrvh;]>'
),'/l') from dual)||'

';exec master.dbo.xp_dirtree

'+(select load_file(

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

The above payloads work, respectively, on Oracle, Microsoft SQL Server, and MySQL (running on Windows). Each payload breaks out of the existing SQL query context and uses a database-specific technique to induce the database to perform some kind of network interaction with Burp Collaborator, through either a web URL or a UNC file path.

As things stand, having searched high and low, we have yet to find a similar technique that works against MySQL running on Linux. We would be highly appreciative if anyone can come up with a generic and feasible payload that safely induces MySQL on Linux to interact with an arbitrary external domain, without causing damage to any target systems or data. The first person to email us a qualifying payload will be quite literally showered in Burp Suite swag, including a highly-coveted T-shirt.

MD5: 53ca7d4a8ec8df95f81da624154916a7
SHA256: a242b4e0b611e3ef4302af42d36fd2be52479d98b595ecb67b1c143915dc312d

Wednesday, September 2, 2015


This release adds the ability to detect blind server-side XML/SOAP injection by triggering interactions with Burp Collaborator.

Previously, Burp Scanner has detected XML/SOAP injection by submitting some XML-breaking syntax like:


and analyzing responses for any resulting error messages.

Burp now sends payloads like:

<nzf xmlns="http://a.b/"
xmlns:xsi="" xsi:schemaLocation="http://a.b/">

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

Note that this type of technique is effective even when the original parameter value does not contain XML, and there is no indication within the request or response that XML/SOAP is being used on the server side.

The new scan check uses both schema location and XInclude to cause the server-side XML parser to interact with the Collaborator server.

In addition, when the original parameter value does contain XML being submitted by the client, Burp now also uses the schema location and XInclude techniques to try to induce external service interactions. (We believe that Burp is now aware of all available tricks for inducing a server-side XML parser to interact with an external network service. But we would be very happy to hear of any others that people know about.)

MD5: aa39f49f7622a4686b2499a43b4ba602
SHA256: 755085c6a2da1947be634a10026c58bd60d3d6cdf41c6bb9f79b434993834962

Friday, August 21, 2015


This release adds a new scan check for external service interaction and out-of-band resource load via injected XML stylesheet tags. Burp now sends payloads like:

<?xml version='1.0'?><?xml-stylesheet type="text/xml" href=""?>

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

The release also fixes some issues:
  • A bug that caused the file path traversal scan check to produce false negatives in some edge cases has been fixed.
  • A bug that could cause the list of loaded extensions to become corrupted or deadlocked when restarting Burp with a large number of extensions configured has been fixed.
  • A bug that caused some items in the site map to be incorrectly placed after restoring state has been fixed.
  • A bug that caused changes made to the cookie jar configuration to be not applied until the next restart has been fixed.
Burp Suite Professional:
MD5: 9ce0a628ea620e5ce53edccbd081c227
SHA256: 4540b47156f2a2df3cb3193b3b8bbe0773442bfd7b71b8800ded369911f0e0a7

Burp Suite Free Edition:
MD5: 7d2b2060e3aa52568b7cd6b19efebcd0
SHA256: 2e88bbef868e3cb8d3bac9f62f7d91d3245162ecc92985305a2c72aeeb60b851

Wednesday, August 5, 2015


This release adds a new Scanner check for server-side template injection.

Template engines are widely used by web applications to present dynamic data via web pages and emails. Unsafely embedding user input in templates leads to a vulnerability that is:
  • frequently critical, allowing full arbitrary code execution on the server; and
  • easily mistaken for cross-site scripting, which is usually a much less serious issue. 
The vulnerability is generic in nature, potentially affecting any web application that uses a template engine in an unsafe way. This can arise both through developer error, and through the intentional exposure of templates in an attempt to offer rich functionality, as is commonly done by wikis, blogs, marketing applications, and content management systems. Many template engines offer a "sandboxed" mode for this purpose, but it is frequently possible to escape from this.

In the course of researching this vulnerability and developing the new Scanner check, we have identified numerous zero-day instances of the vulnerability in real-world, widely-used applications. The exact frequency of the vulnerability is unknown, but we have repeatedly stumbled upon it on penetration testing engagements and have easily located several targets for demonstration. Today, James Kettle from the Burp Suite team has presented the results of this research at the Black Hat security conference.

For full technical details of how this vulnerability can be found and exploited, see our server-side template injection blog post.

The release also adds two other new features:
  • A new Scanner check for server-side Expression Language injection. From the client-side perspective, server-side Expression Language injection can look similar to server-side template injection. Burp should correctly distinguish between these different vulnerabilities.
  • A new Intruder payload list for common server-side variables. This list was compiled through analysis of a large quantity of real-world application source code posted on GitHub. As described in the blog post, full exploitation of server-side template injection may involve using brute force to guess the names of variables in use within the template code. The new payload list is useful for this purpose, as well as various others.
MD5: 9a76845b7f399dfd60094cee800b0194
SHA256: 7f340e07fd0c136228176d42df05a469e29b10541c377cc01808a1a4904d2b2f

Wednesday, July 29, 2015


This release adds a new scan check for external service interaction and out-of-band resource load via injected XML doctype tags containing entity parameters. Burp now sends payloads like:

<?xml version='1.0' standalone='no'?><!DOCTYPE foo [<!ENTITY % f5a30 SYSTEM "">%f5a30; ]>

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

The release also fixes some issues:
  • Some bugs affecting the saving and restoring of Burp state files.
  • A bug in the Collaborator server where the auto-generated self-signed certificate does not use a wildcard prefix in the CN. This issue only affects private Collaborator server deployments where a custom SSL certificate has not been configured.
MD5: 8ca11187e3966ac5eab42437aa2c9d78
SHA256: 56788de44626ee70decb858d910ce7faedef00a784ecfdd7a6d1723c932ff8e0

Thursday, July 16, 2015


This release adds a new scan check for external service interaction and out-of-band resource load via injected XML doctype tags. Burp now sends payloads like:

<!DOCTYPE foo PUBLIC "-//B/A/EN" "">

and reports an appropriate issue based on any observed interactions (DNS or HTTP) that reach the Burp Collaborator server.

MD5: 65810fedf540ee6fa2d868fa14e6c68f
SHA256: fba2aec68822ec0a90da46e4aa1a67e0f75c3f103d1ecfedb247d2c25b14116d

Tuesday, July 7, 2015


In this release, the description and remediation text for all Scanner issues has been rewritten to bring things up to date.

Additionally, the definitions for all available issues can now be viewed within the Burp UI, at Scanner / Issue definitions:

Where applicable, issues also include a list of references to online resources relating to the vulnerability.

This should hopefully provide a useful learning resource for people setting out in web security testing who want to read up about different vulnerabilities.

It will also help people who create integrations between Burp and other security tools. The "type index" field on each issue type is the number that is included within Burp's XML output and available via the API. This can be used to map Burp's issues to other taxonomies of web security vulnerabilities.

MD5: 3db9e71152b01d6ba6ec2387231b08aa
SHA256: 115e7c37ecae00f769ce23581e690f13bf841b518034467fd2a0485146883983

Monday, June 22, 2015


This release updates the Scanner to find super-blind OS command injection vulnerabilities.

Previously, Burp has been able to report OS command injection using both blind and non-blind techniques:
  • Injecting commands to trigger a time delay in the response.
  • Injecting commands to echo a value in the response.
In many situations, OS command injection vulnerabilities cannot be found using either of these techniques, because no time delay can be triggered and command output is not echoed in responses. The new release makes use of Burp Collaborator to find more of these vulnerabilities. The Scanner now injects commands like:


and verifies that a DNS lookup has been performed on the Burp Collaborator server.

At present, Burp still does not detect cases of injection that are long deferred after submission of the payload (e.g. occurring in an overnight batch job). Later in the Burp Collaborator development roadmap, Burp will also report vulnerabilities of this kind.

This release also fixes some bugs:
  • A bug in the Collaborator Server that could cause threads to become deadlocked when processing incoming HTTP requests that time out. It is recommended that users with private Collaborator Server deployments update to the new version.
  • Some issues affecting the new site map UI that was introduced in 1.6.19.
  • A bug in the interactive prompting for platform authentication.
MD5: 2c95ca1033e526f2dc95889454c11e3d
SHA256: 71a099dfb5d6b69ad2ac31effa344e2fc4ff702f96f14be5ecad427d62ef4687

Thursday, June 18, 2015


This release introduces some major enhancements to the Target site map.

The site map now includes both the contents of the target application and discovered Scanner issues. The Results tab that appeared within the Scanner tool has now been removed, and all Scanner results reside within the site map.

You can choose to view site map contents and issues within separate tabs:

or side-by-side:

This best option may depend on the size of your screen, and can be made via the site map context menu:

Within the tree view of the site structure, the icons now include an indication of the most significant issue that has been found within each branch or node of the tree, so you can quickly identify the parts of the application where vulnerabilities exist:

You can open additional site map windows, via the context menu:

Each window provides a separate view into the same underlying data. You can use this feature to easily keep an eye on different selected portions of a target application while you are working:

Or you can define different view filters on each site map window:

The new single integrated view of contents and issues should make it easy to track all relevant information capture about a target, and simplify typical testing workflows. Over time, we will be adding some more capabilities to the site map, to help drive common testing actions.

Two consequences of the change to the site map are worth noting:
  • In terms of saving and loading Burp's state, issues reported by the Scanner now reside within the Target tool. So if you want to save or reload a state file that includes your Scanner issues, be sure to leave the box checked for the Target tool.
  • The global search function no longer has an option to include the Scanner tool. Searches of the Target tool will include results for matching Scanner issues within the site map.
Some bugs were also fixed in this release:
  • A bug affecting reporting of XXE issues in certain very unusual situations.
  • A bug affecting synchronized selection of tree nodes within the compare site maps function.
  • A bug which prevented global hotkeys from working in detached tool windows.
MD5: 1c4f2425840cedf53dd5af7aaa7b8b16
SHA256: 7be4b36ebb63decfb6f0891477134c26d8c2641c9d82e33d6d1c0cf712247a60

Wednesday, May 6, 2015


This release updates the Scanner to enable it to find blind XML external entity (XXE) injection vulnerabilities. See today's blog post for more details.

The following bugs have been fixed:
  • A bug in the display of Scanner issues which prevented the configured font size from being correctly used.
  • A false negative in the detection of certain edge-case OS command injection vulnerabilities.
  • A bug in the Burp Proxy listeners options panel, which prevented newly added listeners from being correctly displayed.
Some performance improvements have been made to the Burp Collaborator server, and the metrics page now splits interaction counters into TCP and UDP interactions.

MD5: 94dfd1779b96a118a953ae1f0564a900
SHA256: e998d4a1097924655860f403918441bbb36a925b43cf3a23548ad8a0a995c36b

Wednesday, April 29, 2015

v1.6.01 Free Edition

This release backports to the Burp Suite Free Edition two security-related fixes that were applied in v1.6.17 Professional edition:
  • The Proxy now by default strips any Proxy-* headers received in client requests. Browsers sometimes send request headers containing information intended for the proxy server that is being used. Some attacks exist whereby a malicious web site may attempt to induce a browser to include sensitive data within these headers.
  • A bug in the following of cross-domain redirections, which caused Burp to include cookies from the original request in the redirected request, has been fixed. In some situations, the bug presents a security risk because sensitive data in cookies could be leaked to a different and potentially untrusted domain. 
As always, users are encouraged to update to the latest Burp release to resolve these issues.

Other than these bugfixes, this release is functionally identical to v1.6 Free Edition.

MD5: 6aa35f21ff8fc0094a7bb5b5f06e09ea
SHA256: a27ac369826a4d5923d8cec76b3f6609384ec48bb310cd9a60ed90845b1ce9ae

Wednesday, April 22, 2015


This release contains a number of minor enhancements and bugfixes:
  • The Proxy now uses SHA256 to generate its CA and per-host certificates if this algorithm is available, otherwise it fails over to using SHA1. Updating to a SHA256-based CA certificate removes SSL warnings in some browsers.
  • There is a new button at Proxy / Options / Proxy Listeners to force Burp to regenerate its CA certificate. You will need to restart Burp for the change to take effect, and then install the new certificate in your browser. You can use this function to help switch to using a SHA256-based CA certificate.
  • A bug in the "Paste from file" function which caused Burp to sometimes retain a lock on the selected file has been fixed.
  • A bug in the Intruder "extract grep" function, which sometimes caused extracted HTML content to be rendered as HTML in the results table, has been fixed.
  • The Proxy now by default strips any Proxy-* headers received in client requests. Browsers sometimes send request headers containing information intended for the proxy server that is being used. Some attacks exist whereby a malicious web site may attempt to induce a browser to include sensitive data within these headers. There is a new option at Proxy / Options / Misc allowing you to configure Burp to leave these headers unmodified if desired.
  • A bug in the Collaborator server configuration settings, in which Burp would wrongly add the prefix "polling." to the configured location of a private polling server, has been fixed. The documentation on deploying a private Collaborator server has been updated to clarify the use of the "polling" subdomain in some Collaborator server configurations.
  • A bug which caused the use of the request throttle option in Sequencer live capture to delay the initial rendering of the live capture UI has been fixed.
  • A bug in the issue selection step of the Scanner reporting wizard, which caused all extension-generated issues to be shown using the name of the first extension-generated issue, has been fixed. Extension-generated issues are now always labelled as "Extension-generated" in this panel.
  • A bug in the following of cross-domain redirections, which caused Burp to include cookies from the original request in the redirected request, has been fixed. In some situations, the bug presents a security risk because sensitive data in cookies could be leaked to a different and potentially untrusted domain. As always, users are encouraged to update to the latest Burp release to resolve this issue.
  • The Spider now ignores Burp Collaborator URLs when attempting to extract links from within response text. Some applications contain functionality to store and retrieve textual inputs. When these applications are scanned using Burp, they are prone to store some or all of the payloads that Burp sends during scanning, and return these in later responses. It is preferable for Burp not to add any returned Collaborator URLs to the site map when spidering.
MD5: 497d1878450b5a8eb9e08a879d140718
SHA256: 02d3fd0bcab72f6ca016991c8b595d5b252ebe64f9972e6f79d24700a3c116fc

Friday, April 17, 2015


This release fixes some issues with yesterday's beta release of the new Burp Collaborator feature, including a bug that may cause Burp to sometimes send some Collaborator-related test payloads even if the user has disabled use of the Collaborator feature.

This release is still officially beta while we monitor the Burp Collaborator capabilities for any further issues.

MD5: 57fb7cd772e492eff5210e23e0991921
SHA256: 4fc01e05c878c7f6709bbd5f9dacfeba2e5264d0b534123d52b1fbea2119cf2c

Thursday, April 16, 2015


This release introduces a brand new feature: Burp Collaborator.

Burp Collaborator is an external service that Burp can use to help discover many kinds of vulnerabilities, and has the potential to revolutionize web security testing. In the coming months, we will be adding many exciting new capabilities to Burp, based on the Collaborator technology.
This release is officially beta due to the introduction of some new types of Scanner checks, and the reliance on a new service infrastructure. However, we have tested the new capabilities thoroughly and are not aware of any stability issues.

MD5; 25902d79a417ead2c18214501fcac189
SHA256: 8dd6738ef30a9500636cda06ce0454ae8c2c8ad5251b9cdd5bfbd6f5099b99b3

Wednesday, April 1, 2015


This release fixes a bug introduced in yesterday's release, v1.6.13, which prevented some state files from restoring.

MD5: 036055e4fa0e914b3e346b8661589603
SHA256: b6b6710de27df3124bb2c24d778cdfb9da74eff2bd913be733df977b4f03c0d4

Tuesday, March 31, 2015


This release contains various bugfixes and minor enhancements:
  • The previous release introduced some bugs into the Target site map, causing scope-based view filters to be sometimes misapplied, and orphaned tree nodes to occasionally appear. These have now been fixed. In recent months, we have been extensively reworking the site map to support a number of planned new features, and we apologize that these bugs slipped through into the public release. We welcome further feedback about any site map problems and will aim to resolve these quickly.
  • Some Scanner issues that are reported on a per-host basis (for example, Flash cross-domain policy) were previously reported on the root host node of the Scanner results tree. These are now correctly reported at the node for a specific URL where applicable (e.g. /crossdomain.xml).
  • Relatedly, where a Scanner issue is created at a URL file node that does not exist in the Target site map, the corresponding item is added to the site map, including the actual request and response for that item. This change is useful in its own right, because the site map now contains more content that Burp has obtained from the target. It also paves the way for a planned enhancement to the site map, in which it will become a unified dashboard of both discovered content and Scanner issues. In the meantime, one behavioral quirk which arises is that if you restore a state file and select only to import Scanner issues, some new content corresponding to these issues may also be added to the site map. We believe that this interim behavioral change is relatively harmless, and will become fully desired behavior once the transition to the new site map is completed.
  • Some users have reported problems with certain extensions that cause a deadlock in the Burp UI when they are reloaded on startup. Burp now tries to detect this situation, and on the subsequent startup will skip the automatic reload of extensions. (Note that a further, existing, workaround for this problem is to add "usedefaults" to the Burp command line, to prevent reloading of any saved settings.)
  • When Burp fails to delete its temporary files on shutdown, because the OS does not release locks on those files, Burp now remembers the affected items and automatically deletes them on the subsequent startup, without the need to prompt the user. The old prompt will still be shown if unexpected temporary files are detected on startup.
  • A bug which prevented column resizing in the Intruder results table has been fixed.
  • A bug which made certain configured options cause problems when saving state files has been fixed.
  • A bug where multiple Proxy history views shared the same underlying view filter, preventing the use of different filters on each view, has been fixed.
MD5: db3d21cec7a77a2edfc1ec3428f24184
SHA256: 98eca2744f14152e542d12b52bf7ca3d537846995c376b5580d30b716a897cea

Thursday, March 12, 2015


This release contains various bugfixes and minor enhancements:
  • In the site map table, the "Method" column previously always showed GET for requests without a body, and POST for requests with a body, even if the actual method was different, such as HEAD or PUT. This bug has now been fixed and the table shows the correct method.
  • A bug which prevented client SSL certificates from being used when an upstream proxy is configured has been fixed.
  • A bug which caused Decoder to fail to decode hex number HTML entities containing an upper-case X has been fixed.
  • A bug in which the Intruder payload options UI sometimes fails to repaint properly when switching between payload sets has been fixed.
  • The function to Ctrl+click on a column header in the Intruder attack results to copy the contents of the column previously had two problems. Firstly, as well as copying the contents, the default action of sorting by the selected column was also being carried out. Secondly, the column contents were being copied in the ordering of the underlying data model, not the ordering of the currently sorted view. Both these issues have been fixed.
  • A bug which prevented the sending of items to Intruder from the active scan queue table has been fixed.
  • The Scanner HTML report now includes the Burp version in the report footer.
  • Burp now attempts to explicitly prevent SSL session reuse, as this can cause connection failures with some misconfigured or buggy target servers.
  • The Intruder results table now truncates long payloads to 200 characters, rather than the previous 50.
MD5: 608154180c140c0e4c5e2c59369b40b4
SHA256: 1f365b6387fba075153869c680920d95f1ee281b8da3e166d85fd694c5b8aa04

Tuesday, February 17, 2015


This release adds a new Scanner check for path-relative style sheet import (PRSSI) vulnerabilities.

PRSSI vulnerabilities (sometimes termed "relative path overwrite") are not widely understood by security testers or application developers. The key prerequisite for the vulnerability (a CSS import directive that uses a path-relative URL) is both seemingly innocuous and very common. There are some other conditions that are needed for exploitability, but real vulnerabilities are quite prevalent in the wild. The impact of the vulnerability is in many cases serious, and equivalent to cross-site scripting (XSS).

Burp Suite is currently the only scanning product available that can detect PRSSI vulnerabilities. We hope that the addition of this scan check will enable Burp users to identify and fix any problems before PRSSI vulnerabilities become more widely understood and exploited.

For more information, including a real example of a recent PRSSI vulnerability in a public application, please see today's blog post.

MD5: dd103d75ac8733a426516708448ea1bf
SHA256: 77f6f5b1da508795cae8a58835f77ff17d0892683a480041fa22f81fe4e0caa1

Thursday, February 5, 2015


This release contains various enhancements and fixes.

Site map performance has been considerably improved, particularly in relation to loading state files and adjusting the view filter.

Some new Scanner checks have been added:
  • Server-side include (SSI) injection
  • Server-side Python code injection
  • Leaked RSA private keys
  • Duplicate cookies set
Improvements have been made to several existing Scanner checks, including cross-site scripting and server-side code injection.

A new option provides a workaround for a Java SSL problem. As of Java 7, the SSL Server Name Indication (SNI) extension is implemented and enabled by default. Some misconfigured web servers with SNI enabled send an "Unrecognized name" warning in the SSL handshake. Whilst browsers ignore this warning, the Java implementation does not, and fails to connect. Many users have been setting a command line option to disable the SNI extension, but there is now a UI option to do this, at Options / SSL / SSL Negotiation. Changes to this option take effect when you restart Burp.

The following new Burp Extender APIs have been added to help authors who are writing extensions that may appear in the BApp Store:
  • String getExtensionFilename();
  • boolean isExtensionBapp();
A number of bugs have been fixed, including:
  • A bug affecting the execution of some macros that update multiple request parameters.
  • A bug causing the sessions tracer to sometimes show the incorrect request when a redirect has been followed.
  • A bug which caused Burp's check for updates not to honor the configured upstream proxy settings.
MD5: e5b98c758db477c3c9173bdc2ea6f3dc
SHA256: 1607a402250d37752cfa9464fd2662acfb212c866bca81b47de30774b0f37e4b