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, January 27, 2016


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


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

Saturday, January 16, 2016


This release fixes a bug that was introduced in 1.6.33. The effect of the bug was that state files generated by 1.6.33 containing certain newly discovered Scanner issues would fail to restore properly. The bug is now fixed and the affected state files generated by 1.6.33 should now restore correctly.

MD5: 62157ff3377cb139729cc1f7d83be7d5
SHA256: 77b28f05e8abbdf479554e1b5851f85aa5241ca1e81e5c5a233b214508d3c515

Wednesday, January 13, 2016


This release adds the ability to detect blind XSS, via Burp Collaborator.

Blind XSS is a special type of stored XSS in which the data retrieval point is not accessible by the attacker - for example, due to lack of privileges. This makes the vulnerability very difficult to test for using conventional techniques. In many cases, there is no hint whatsoever in the application's visible functionality that a vulnerability exists. Since security testers are in the habit of spraying target applications with alert(1) type payloads, countless admins have been hit by harmless alert boxes, indicating a juicy bug that the tester never finds out about. Due to the inherent difficulty in detecting blind XSS vulnerabilities, these bugs remain relatively prevalent, still waiting to be discovered. This new release of Burp empowers testers to easily find these critical vulnerabilities, with no special configuration or other tools required.

Previously, Burp Scanner has used purely in-band techniques to detect stored XSS. This involves first scanning the data entry point, later scanning the data retrieval point, identifying the connection between the two, and then supplying suitable payloads to the entry point to formulate a proof-of-concept attack. This approach can often be effective, but has some significant limitations:
  • It cannot detect blind XSS, because the data retrieval point is not accessible.
  • It requires that the entry and retrieval points are scanned in the correct order.
  • It is highly vulnerable to previously submitted data being overwritten by another user's actions in the time between scanning the entry and retrieval points.
Burp still uses conventional in-band techniques to detect stored XSS, but now also sends payloads like this:

This payload starts with a multi-context break-out sequence which, in all normal retrieval locations, will convert the HTML context to one where JavaScript can be executed. It then executes some script that triggers a connection to the Burp Collaborator server. This out-of-band interaction enables Burp to confirm when the payload has been successful. For more details on the breakdown of this payload, see our blog post on hunting asynchronous vulnerabilities.

The new approach to finding stored XSS has some significant benefits:
  • It can detect blind XSS, provided that another user, such as an administrator, eventually views a page containing the stored payload.
  • It only requires that the entry point be scanned by Burp. Other users' interaction with the application, or the Burp tester's own browser-based use of the application (if non-blind), is likely to lead to connections to the Collaborator server that enable Burp to report the issue.
  • Even where the stored data is short-lived, and has been overwritten by the time the Burp tester visits or scans the retrieval point, Burp may still detect the issue due to other users viewing the data.
  • As with other deferred Collaborator interactions, Burp can report stored XSS issues after the Burp user has finished testing, without any additional requests to the application.
Below is an example of what Burp's advisory looks like for a blind XSS issue that has been discovered via Burp Collaborator. This example uses a simpler payload that works in many situations. Note that Burp nicely identifies the Referer header from the incoming HTTP request to the Collaborator server, which will normally indicate the retrieval point where the payload appeared:

MD5: b032280fbfdc77395e9ef896c8d1b976
SHA256: c7ac01d3819094f314b57deb12cd63a3e1e1a4c6d9bd7f1e4a29cbf4e7b8f4b1