login

Burp Suite, the leading toolkit for web application security testing

Burp Suite Professional - Release Notes

Tuesday, July 26, 2016

1.7.04

This release introduces a new tool, called Burp Infiltrator.

Burp Infiltrator is a tool for instrumenting target web applications in order to facilitate testing using Burp Scanner. Burp Infiltrator modifies the target application so that Burp can detect cases where its input is passed to potentially unsafe APIs on the server side.

The initial release of Burp Infiltrator supports applications written in Java or other JVM-based languages such as Groovy. Java versions from 4 and upwards are supported. In future, Burp Infiltrator will support other platforms such as .NET.

For more details about how Burp Infiltrator works, how to use it, and some other important considerations, please refer to the Burp Infiltrator blog post and the Burp Infiltrator documentation.

Burp Infiltrator makes use of Burp Collaborator for its communications back to the instance of Burp Suite that is performing scans. To support this, some new capabilities have been added to Burp Collaborator. Users who have deployed a private Burp Collaborator server should upgrade to the new version.

Some minor bugs have been fixed, including:
  • A bug which caused the values of some project options to change when an existing Burp project is reopened.
  • A bug which prevented editing of macro requests when using a disk-based project.
  • A bug which prevented the hostname from being correctly parsed from some TLS client hello messages when Burp Proxy is running in invisible mode.
MD5: 85ab62c473e2be60d8da15ccc0c80cde
SHA256: 43fede912099ff0af99ac595ca45b56aef3af4a5743c5b5d3107ed170da74551

Thursday, May 12, 2016

1.7.03

This release adds some enhancements to, and fixes some minor issues with, the Burp projects feature:
  • If the operating system exits abnormally when Burp is running with a disk-based project then some in-memory data may not be saved to disk, resulting in a partially corrupted project file. On reopening a project, Burp now detects this condition, and offers to repair the project file. The repair process will preserve as much data as possible from the corrupted project file.
  • When a new project is created, at the second step of the startup wizard where a configuration file is selected, Burp now lets you specify to use the selected option by default in future. If you have created a configuration file that you prefer to use for new projects, using this feature avoids the need to manually select your configuration file every time.
  • In the startup wizard, the lists of recently used project and configuration files now automatically hide any items that no longer exist on disk.
  • Burp now prevents selection of the current project file in all file dialogs, to avoid accidental overwriting of project data.
  • A bug that could lead to bloating of project files with redundant data has been resolved.
Thanks are due to everyone who has provided feedback about the new projects feature since the 1.7beta release. Based on the enhancements made since that release, the projects feature is now officially out of beta, and this release may be regarded as stable. As with all Burp features, we welcome ongoing feedback about the projects feature as people continue to use it.

Burp Suite Professional:

MD5: f104167fd64b8212e0b1b4c65736aa91
SHA256: 2fa319e45a91c9ccc6e96dee3e362f62be9a6e1dff84827d99830d4703913ba4

Burp Suite Free Edition:

MD5: a6019d5cbea725c44342303084343ade
SHA256: f5c83a2cfa4bdf9010d7033f0e66cc76bfd732cccfcc279ef7b14078046161d1

Monday, April 25, 2016

1.7.02beta

This release improves the resilience of disk-based projects in situations where the operating system terminates abnormally.

Burp uses memory-mapped files for disk-based projects. The operating system has responsibility for synchronizing data held in memory with files on disk, and ensures eventual consistency even if an individual process crashes. However, if the operating system itself crashes, then some in-memory data may not be written to disk, leading to a partially corrupted project file. Burp now tries to reduce the impact of this event, by forcing the operating system to write to disk more frequently, and by reopening project files in a more fault-tolerant manner. We are continuing to investigate ways of avoiding data loss in the event of the operating system terminating abnormally, and expect to make further enhancements in future releases. For this reason only, we are continuing to describe the disk-based projects feature as being in beta.

MD5: 9ffbaf30d02f13dfca3f694a946147ba
SHA256: 48a2370ee0cac43d8aca3b97563c24b9b66fc65b9197a75282394900a5a8ad73

Monday, April 18, 2016

1.7.01beta

This release fixes a number of minor bugs:
  • A bug affecting the sending of some requests from Intruder to other tools when a disk-based project is being used.
  • A bug that could sometimes cause the SSL client certificates configuration UI to become corrupted when restoring settings that are not valid on the current machine.
  • A bug that could sometimes cause superfluous semicolons to be introduced into requests when manipulating cookie parameters via the API.
  • A bug that could very occasionally cause Burp Proxy's processing of HTTPS requests to stop working.
Although we are not aware of any significant bugs in version 1.7, this update is still officially a beta release, to allow more time for bugs to be identified.

Burp Suite Professional:

MD5: 2d75c238f00906dc415f8cb115399317
SHA256: 41fd0d33e0fce1d68c11100e6d1e73b85a97fd65a56c083b64411309ba39ac0f

Burp Suite Free Edition:

MD5: f645734ecd263ad713f024ca00fa0d15
SHA256: f5bb8e45b3a0873c64c443e9bf68f8ec90e682a544e335571398da039e81ebcb

Tuesday, April 12, 2016

1.7beta

This major release introduces several new features, including:
  • Burp projects
  • Burp configuration files
  • A new startup wizard
  • New APIs
  • New command line arguments
Full details about the new features can be found on the Burp projects blog post.

Note: This is a beta release and disk-based projects are an experimental feature. The release should be used with caution, as it may contain bugs that cause unexpected behavior including loss of data.

The release also fixes a bug in the Collaborator server that may cause loss of service if unexpected interaction data is received. Users who have deployed their own private Collaborator server should update to the latest version as soon as possible. The Collaborator server function in the new release may be regarded as stable and suitable for production use.

Burp Suite Professional:

MD5: 77b6daf566b4d5abdf5ff725edfbc946
SHA256: 4931f5d6351614a357a8ccb3edff5c9c4f9fe14cefb0966547187b2da93a0d45

Burp Suite Free Edition:

MD5: 9851e2c48ce91e6e9b47b789aec50245
SHA256: 6b02a74fa537504c8df4d7901cfe293a7ecb97aac91f06550498b7b73f382ea3

Thursday, March 3, 2016

1.6.39

This release improves the logic of some scan checks that depend upon the content type of responses.

Burp has previously reported content type incorrectly stated on any occasion where the stated content type of a response differs from the actual content (as determined by Burp). This has frequently led to a lot of noise because (a) Burp's own content type sniffing has not been perfect; and (b) many content type mismatches have no security implications. Hence, many users got accustomed to just ignoring this issue, despite the fact that, in some rare situations, it can lead to high-severity issues like cross-site scripting.

The cases where this issue matters occur when a response is intended to actually contain non-HTML content such as an image, but a browser may attempt to interpret the response as HTML based on the stated content type. This can lead to XSS if the content is dynamically generated, uploaded by a user, or otherwise contains user input.

In the real world, browsers' actual sniffing of responses depends on several factors, including:
  • The stated content type
  • The presence of the header X-content-type-options: nosniff
  • The file extension of the request URL
  • The browser type and version
The Burp research team have generated every possible permutation of these factors and identified all of the permutations that might lead to a browser attempting to interpret a response as HTML. This knowledge is now baked into Burp, so that Burp only reports the issue when a suitable combination of the above factors is observed. Further, the Burp advisory identifies precisely which browsers may be affected by an issue:


The other type of issue where the situation arises is cross-site scripting. In the past, Burp applied XSS checks to all responses that were either stated or appeared to contain HTML. The scan logic has now been tightened to be more accurate and informative in cases where exploitability of the issue depends upon browser sniffing:
  • Burp now uses its knowledge of actual browser behavior (based on the factors listed above) to determine whether any browser might attempt to interpret a response as HTML.
  • If content sniffing depends on the request URL having a different file extension, Burp will attempt to manipulate the extension so as to trigger this.
  • Any relevant details about specific browsers' behavior is included in the issue detail.
  • Seemingly unexploitable issues are still reported as informational, because a manual tester might nonetheless be able to find a way to exploit them.


Unrelatedly, the configuration of client SSL protocols and ciphers has been modified to include a master toggle specifying whether to use the default protocols and ciphers of the Java installation. This is the new default option, and can be overridden to allow configuration of specific protocols and ciphers. This change simplifies the configuration UI and makes it easier to share Burp configurations between different machines.

MD5: 8b4d1bad5f919d85fa09be7e35fba92f
SHA256: 2ff45ca7f1f3a01e675bfff7a2fa9804475102291085afa88dbdeca2b353a211

Wednesday, February 24, 2016

1.6.38

This release adds the capability to report reflected DOM-based and stored DOM-based vulnerabilities.

Burp already reports reflected XSS (where reflection of input allows direct execution of supplied JavaScript) and DOM-based XSS (where data is read from a controllable DOM location and processed in a way that allows execution of JavaScript). Burp now joins these steps together, to handle cases where:
  1. The server returns reflected or stored input in the value of a JavaScript string.
  2. That string is processed in a way that allows execution of JavaScript code from within the string.
The new capability applies to all of the DOM-based vulnerability types that Burp can report, such as JavaScript injection, WebSocket hijacking and open redirection.







MD5: cdba3138c9c0a92f1c2b19171db26e92
SHA256: 7bbd5500bb21a87fda1660f394d828d6c3bdcecc5df951a4f9e81a52dc28e62f

Friday, February 12, 2016

1.6.37

This release gives the Scanner the capability to report all instances where user input is returned in application responses, both reflected and stored:



The information gathered is primarily of use to manual security testers. Some applications contain numerous instances of input retrieval, since it is very common for the entire URL to be reflected within responses. For these reasons, the new Scanner checks are off by default, but can be turned on in the Scanner options:



MD5: d0287d85d288c2af116e0d60878a8a24
SHA256: 318a5544d92b137efb22d4935b343a1af4b610cf67bc6a8b89170d3a33d92dce

Wednesday, January 27, 2016

1.6.36

This release adds a new scan check for client-side template injection.

It is very common for applications that use AngularJS to incorporate user input into HTML responses within the client-side template. AngularJS has a long history of sandbox escapes that permit execution of arbitrary JavaScript via template expressions. Hence, when user input is echoed within AngularJS templates, it is frequently possible to perform XSS attacks using minimal syntax that is not usually sufficient to perform XSS, and so not blocked by input filters.

See today's blog post for a full description of this issue, and a list of sandbox escapes in recent versions of AngularJS.

MD5: 50d6256805893e5105941f5d85ca2c3d
SHA256: 2335c3111ea8e3ba7d53ace55f2f69761843aab5e53460a89137a945cb4ccf8a

Thursday, January 21, 2016

1.6.35

This release adds the capability to report three new Scanner issues relating to HTTPS:
  • Unencrypted communications - This is reported when requests are made to a host using plain HTTP. In the near future, browsers will display a prominent security warning whenever this occurs. Due to recent revelations about the mass interception of unencrypted communications by various powerful adversaries, there is a push to use HTTPS everywhere. See the screenshot below for more details.
  • Mixed content - This is reported when a page is loaded over HTTPS but loads other resources, such as scripts and images, over plain HTTP. Modern browsers are disabling the affected resources by default, leading to usability issues when mixed content is used. If a user elects to re-enable mixed content, then this presents a security issue.
  • Strict transport security not enforced - This is reported when a host fails to prevent users from connecting to it over plain HTTP, using the Strict-Transport-Security header. In this situation, a suitably positioned attacker can bypass the use of SSL by rewriting HTTPS links as HTTP.


MD5: c716529989c152f99e1f82ed78e99aad
SHA256: 9cd602308d405e4d9b5c39c0b62ca3a351a20bbc794c7d82d62300abcbdbb703

Support Center

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

Visit the Support Center ›

Copyright 2016 PortSwigger Ltd. All rights reserved.