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

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

Monday, July 1, 2013


This release includes various small enhancements and bugfixes:
  • The Repeater tool now lets you configure the layout of the main request and response views. You can display these in a left/right split, a top/bottom split, or in tabs. You can change this setting via the Repeater menu.
  • There is a new extensibility API: IBurpExtenderCallbacks.sendToComparer().
  • There are new settings to enable session handling rules to be in scope for the Extender tool, and to update Burp's cookie jar based on traffic via Extender, allowing requests made by extensions to be fully integrated with Burp's session handling mechanisms.
  • A bug where Burp fails to wait on exit if a scheduled automatic backup is already in progress, causing the backup file to be truncated, has been fixed.
  • A bug that prevented the saving of state in some situations has been fixed.
MD5: 293622d21115bb1c9a941fe093609620
SHA256: 7070e747c6386fd206d091856e75d77d2f09eda585d84191550f6051388eea54

Tuesday, June 25, 2013


This release includes fixes for the following issues:
  • A bug where repeating an Intruder attack using null payloads may generate no attack requests.
  • A bug where the default save location for automatic updates to Burp may contain URL-encoded characters, resulting in an invalid file path.
  • An issue where the CSRF PoC generator output using the cross-domain XHR technique fails to work on current versions of the Chrome browser.
  • Burp's behavior in quitting immediately without warning on OS X when Command+Q is pressed.
  • Poor performance saving and restoring state in v1.5.12.
MD5: 52900384fffe42121a4977c1b8ae2b90
SHA256: d89381858cec5c450c4b490e66511b47f884f0bac7c8ded2ca4a860c4673dc2e

Wednesday, June 12, 2013


This release contains various enhancements and bugfixes:
  • There is a new payload type in Intruder, which copies the value of the current payload at another payload position. You can also define processing rules to systematically derive one payload from another, rather than copying its literal value. This function is useful in cases where you need to submit the same payload in two locations, or where one parameter is derived from (e.g. a hash of) the parameter that you need to test.
  • You can define Proxy interception rules based on the listener port number, so you can e.g. prevent interception of all messages on a specific listener.
  • The IResponseInfo interface has two new methods: getStatedMimeType() and getInferredMimeType().
  • The memory overhead of saving and restoring state, and performing search operations, is reduced.
  • The Scanner no longer prompts the user for confirmation when an extension programmatically initiates a scan of an out-of-scope item.
  • The problem with superfluous whitespace characters appearing when text is copied from the Scanner advisory panel into another application has been resolved.
  • The CSRF PoC generator now properly escapes tag brackets when using the XHR method, to prevent any closing script tags that are required within the generated request message from breaking the PoC script.
  • Parameter matching between macro items now tolerates URL-encoding of parameter names when performing matching.
  • A bug where certain nonprinting characters were corrupted when loading Intruder payloads from a file has been resolved.
MD5: 2f0d5560ba63c02748b6cad2542a12e7
SHA256: 266c0c5eb5837f8fac32ce5343278a181f191e72b36c619d557ed351c7d5aad9

Thursday, April 11, 2013


This release fixes a bug affecting HTML scan reports for some users.

MD5: 74ac6b837dc3152bab26a5cc063f2428
SHA256: d68baa37933516f2c8a9851b5a3a3aa280e63d740b2bf4f570f9c08209162ae0

Wednesday, April 10, 2013


This release includes the following additions:
  • In-tool updates for future releases. From the next release, you will be able to download updates from within Burp itself, without needing to log in to our website.
  • A new improved Scanner reporting format. View a sample report.
  • A new API for generating Scanner reports programmatically: IBurpExtenderCallbacks.generateScanReport().
  • Fixes for some issues that prevented Burp from working with some PKCS#11 smart cards.
MD5: 36b84819bd1ad65caae9ed4d4d43aec2
SHA256: 465152985a1f3b3c174d2d6057a374a98e1241486bdc537c83f2dad3eefd903b

Tuesday, March 26, 2013


This release adds support for PKCS#11 client SSL certificates contained in smart cards and other physical tokens. These can be configured at Options / SSL / Client SSL Certificates.

Key features include:
  • Ability to configure multiple PKCS#11 and PKCS#12 certificates for use with different hosts (or host wildcard masks) .
  • Auto-detection of installed PKCS#11 libraries (currently Windows only).
  • Auto-detection of card slot settings.
  • Support for OS X, Linux and 32-bit Windows (note that Oracle Java does not currently support PKCS#11 on 64-bit Windows).
  • Persistence of configuration across reloads of Burp.
Although we have tested the PKCS#11 support using numerous cards on various platforms, please do let us know if you have problems with particular devices.

This release also adds an option to encrypt passwords contained in Burp's configuration options when these are saved in persisted preferences or Burp state files. This option is available via the Burp menu / Remember settings / Passwords, and also within the save state wizard. If the option is selected, Burp will prompt you for a master password with which to encrypt individual passwords. The master password is not saved anywhere. When the settings are later restored, Burp will prompt you for the master password to decrypt the individual passwords. For those who are interested, this feature uses AES encryption with a 128-bit key generated from your password using PKCS#5v2.0.

MD5: b5a6b8c240ae4ee1c3c26273a95c4a8f
SHA256: 69d339db54e50d8732096305199d4e3f758b1e881269427deea1f65315471d34

Tuesday, March 12, 2013


This release includes various minor enhancements and bugfixes, including:
  • The Proxy has a new option to unpack compressed request bodies (previously only compressed responses were supported). This option is off by default as it may break some applications that require compressed requests.
  • Decompression of compressed content now works with .NET DeflateStream compression, and a bug affecting some other deflate implementations has been fixed.
  • The default Proxy match and replace rules include an available item to remove the Accept-Encoding header in requests, to deter servers from compressing response content.
  • The active scan queue is now much more responsive, in terms of providing real-time information about progress, and responding to cancel/pause actions.
  • A bug affecting NTLM negotiation with some servers has been fixed.
  • A bug which occasionally caused the Proxy history filter panel to become uneditable has been fixed.
  • A bug affecting the generation of per-host SSL certificates using a custom CA certificate that has been imported from another tool, has been fixed.
  • The function to save and restore state now provides verbose debug output on error, to facilitate debugging of problems.
  • A bug affecting the parsing of some ASP.NET ViewState structures has been resolved.
MD5: 235e5f4c79772184b9c17674e8fdbe22
SHA256: 5090c9a2d2feb4cb73f7c0377beb57dc909ee07363a415aba59d320c167c1904

Wednesday, February 27, 2013


This release fixes a bug introduced in yesterday's release that prevented the button to add a new extension from working in some situations.

MD5: 215792296cd2628e2de8121b416cb476
SHA256: 1160ade5291dd2ebf8b7279b9aec5eafd5f1145fc5243af1888428a9d616b84c

Tuesday, February 26, 2013


This release adds a number of useful new features and bugfixes.

New CSRF technique

The CSRF PoC generator adds a new technique to generate requests using cross-domain XmlHttpRequest (XHR). This allows the submission of arbitrary binary request bodies together with any "standard" Content-Type header, including "application/x-www-form-urlencoded" and "multipart/form-data". One obvious use for the new technique is that it allows for cross-domain file upload, where a filename attribute needs to be included in a multi-part message body.

The cross-domain XHR technique requires a modern browser that is capable of cross-origin resource sharing (CORS). CORS allows XHR to make arbitrary cross-domain requests. However, if a request contains any "non-standard" features (method, headers or content type) then the request is "preflighted". Here, the browser first verifies whether the destination server is configured to accept cross-domain requests of the relevant type, and this will normally cause the attack to fail. On the other hand, if a request contains only "simple" features (roughly, those that can be generated using a standard HTML form) then the request is not preflighted: the browser simply makes the full cross-domain request, and adds an Origin header identifying the domain from which the request originated. Servers will typically ignore the Origin header and process the request in the normal way.

The loophole provided by the XHR technique is that it allows us to create requests with a "normal" Content-Type header together with completely arbitrary content in the message body. So in the case of cross-domain file upload, we can include the required filename attribute in a way that cannot be done in a pure HTML form (unless, of course, the victim user is induced into selecting a file to upload).

The following points should be noted about the cross-domain XHR technique:
  • It includes the browser's cookies in the normal way, and so works with authenticated (in-session) requests.
  • It requires a relatively recent browser, and works on current versions of Firefox, Internet Explorer and Chrome.
  • The application's response is not processed by the browser in the normal way, so the technique is not suitable for making cross-domain requests to deliver reflected cross-site scripting (XSS) attacks.
  • If you try to generate a PoC for a request containing any unusual features that may trigger a preflighted request, Burp will do its best to construct a valid PoC, and will warn you about the problematic features.

New SSL options

Several new options are available for SSL negotiation. You can now individually select which SSL protocols and ciphers to use:

Two new options are also available to help work around common problems in SSL negotiation:
  • "Automatically select compatible SSL parameters on negotiation failure" - If this option is enabled, then when Burp fails to negotiate SSL using the configured protocols and ciphers, it will probe the server to try and establish a set of compatible SSL parameters that are supported by both the server and Java. If compatible parameters are found, Burp caches this information and uses the parameters in the first instance for subsequent connections to the same server. This option is generally desirable and can avoid the need to troubleshoot SSL issues and experiment with protocols and ciphers.
  • "Enable algorithms blocked by Java security policy" - As of Java 7, the Java security policy can be used to block certain obsolete algorithms from being used in SSL negotiation, and some of these are blocked by default (such as MD2). Many live web servers have SSL certificates that use these obsolete algorithms, and it is not possible to connect to these servers using the default Java security policy. Enabling this option allows Burp to use the obsolete algorithms when connecting to the affected servers. Changes to this option take effect when you restart Burp.
Both these new options are enabled by default.

Other updates

The release includes the following new features and bugfixes:
  • When doing invisible proxying of SSL connections, Burp now inspects the Client Hello message for the server_name extension. If this is present, Burp uses it to generate per-host CA-signed certificates in the normal way.
  • To facilitate development and debugging of extensions, you can now fast-reload an extension by Ctrl+clicking the "Loaded" checkbox in the table of extensions. The extension will be unloaded and reloaded without displaying a confirmation dialog. Further, extensions will now reuse the existing output window if one was already created for that extension.
  • The IInterceptedProxyMessage interface has two new methods, getListenerInterface and getClientIpAddress, which you can query to obtain details about the Burp Proxy listener and the client for the intercepted message.
  • The scope configuration UI now lets you load a list of items from a text file. Each item in the list should be either a URL or a domain name, and Burp will create appropriate scope rules accordingly.
  • A bug where sending requests from the Target Analyzer to other Burp tools always results in non-parameterized GET requests being sent, has been fixed.
  • A bug in the display of messages where character set encoding is wrongly applied to HTTP headers, making them unreadable in some cases (e.g. UTF-16LE) has been fixed.
  • There is a new workaround to try to prevent OS X from periodically deleting Burp's temporary files when using the default location.
MD5: 4345ed9cce9c559026875339464542fd
SHA256: d2afec9496756320e3d9df60879340049f155ffd63e63e74b60225e264130a6d

Friday, February 15, 2013


This release contains a number of feature enhancements and bugfixes, including:
  • The SOCKS proxy support now has an option to perform DNS lookups remotely via the proxy. This enables Burp to access TOR hidden services, and to work in some unusual infrastructures. When this option is enabled, no local DNS lookups will be performed by Burp.
  • The per-installation CA certificate and key used by Proxy listeners to create per-host certificates can now be exported for use with other tools or another instance of Burp. You can also import a certificate and key into the current instance. The export/import function can be accessed via the Proxy listener configuration panel. Note that you should not disclose the private key for your certificate to any untrusted party. A malicious attacker in possession of your certificate and key may be able to intercept your browser's HTTPS traffic even when you are not using Burp.
  • Your CA certificate (not the key) can now be downloaded by visiting http://burp/cert in your browser (configured to use Burp as its proxy). This makes it easier to install the certificate on some mobile devices.
  • The IBurpExtenderCallbacks interface has two new methods, unloadExtension and get CommandLineArguments.
  • The implementation of per-extension persistent preferences has been modified to use sub-nodes of Burp's preferences store, allowing extensions to use much longer preference names. Preferences saved by extensions using earlier versions of Burp will unfortunately be lost.
  • There is a new option in Burp Proxy's miscellenaeous options to disable logging to the Proxy history and target site map. This option may be useful if you are using Burp Proxy for some specific purpose, such as authenticating to upstream servers or performing match-and-replace operations, and you want to avoid incurring the memory and storage overhead that logging entails.
  • The Target Analyzer function now includes a column in the parameters view to show the value observed for the selected parameter in each request that uses it.
  • There is now a command-line license activation process for use in headless installations of Burp.
  • Burp now allows interactive debugging of extensions.
MD5: 07d3f8578ba8d489e8f2c994843d60b1
SHA256: 30ed3751a34ba98a684aec42a2843b63d38e5fad157689dd67fa82b92f996cf5

Wednesday, January 9, 2013


This release adds an in-tool repository for the new extensibility APIs. The Extender / APIs tab lists all of the interfaces available in the current build of Burp, and lets you browse these and save the interface and Javadoc files locally.

Various updates have been made to the draft extensibility API, based on user feedback:
  • IBurpExtenderCallbacks has two new methods, saveExtensionSetting() and loadExtensionSetting(), which extensions can use to persist configuration settings across reloads of the extension and of Burp.
  • You can now register an IScopeChangeListener to be notified when changes occur to the suite-wide target scope.
  • There is a new ICookie interface, for holding details of HTTP cookies.
  • IResponseInfo has a new method, getCookies(), which you can use to obtain details of any cookies that were issued in a response.
  • IRequestInfo has a new method, getBodyEncoding(), which you can use to determine the encoding used for the message body (URL, multipart, XML etc). Extensions that provide custom scanner checks can use this method to determine the appropriate encoding to apply to attack payloads that are being placed into insertion points in the request body.
  • IBurpExtenderCallbacks has two new methods, getCookieJarContents() and updateCookieJar(), which extensions can use to query and update Burp's session handling cookie jar, for use when dealing with unusual session handling mechanisms.
  • The IBurpExtenderCallbacks method customizeUiComponent() now cascades the action automatically to child components, to reduce the number of calls that you need to make to this method.
  • The IIntruderPayloadGeneratorFactory method createNewInstance() now receives an instance of a new interface, IIntruderAttack, which the extension can use to obtain details about the Intruder attack in which the payload generator will be used.
The last point is the only case where a method signature within the draft API has actually changed (as opposed to new methods and interfaces being added), so hopefully there are mininal effects on any extensions that people have created using the draft API.

The new API is now "final", in the sense that we only anticipate making small incremental changes to the API for the foreseeable future, and those changes should be backwards compatible.

The final API and links to all the sample extensions are available here.

MD5: b8504df0907180c7ac887273f309fc14
SHA256: 099a26e903c0021ebf9a208ad62e86b41f77a6f27e541b1e640656e04b6bb58c