v1.3

Stable release incorporating all of the features contained in the beta releases.

Many thanks to everyone who made feature requests and provided feedback on the beta versions.

v1.3beta2

As well as various bugfixes, this release adds some handy conversion functions to the request/response editor, which are accessible via the context menu and shortcut keys. To use these, simply select the text you want to convert, and choose the relevant conversion:

Available conversions include URL-encoding, HTML-encoding and Base64-encoding. You can also convert raw data into a "constructed string" for various code-injection contexts. For example, selecting the expression:

xss

and choosing "JavaScript constructed string" will convert this to:

String.fromCharCode(120,115,115)

This release also improves Mac compatibility in the message viewer/editor. Keyboard shortcuts now work with both the Ctrl and Command keys. And you can display the context menu without losing the current text selection. If you're experiencing other Mac pain, do let me know.

v1.3beta

This release adds numerous new features. See the preview for full details, but here are the highlights:

• Improved search, with regex, scope restrictions, dynamically updating results, etc.

• Request annotation.

• Fine-grained upstream proxy rules.

• Automated content discovery.

• Scripts and comment search.

• New display filters.

• Wizard for performing active scans of multiple items.

• Manual testing simulator.

• Exporting of request metadata in XML format.

• Target analyser.

Have fun!

v1.2.17

Burp Scanner now allows reporting of issues in XML format, to enable easy integration with other tools. To create an XML report, simply select the issues you wish to report, and choose XML within the reporting wizard:

The XML has a flat structure, and contains a list of issues, with meta-information about issue type, URL, etc., reported within each issue element. The (internal) DTD looks like this:

<!DOCTYPE issues [
<!ELEMENT issues (issue*)>
<!ATTLIST issues burpVersion CDATA "">
<!ATTLIST issues exportTime CDATA "">
<!ELEMENT issue (serialNumber, type, name, host, path, location, severity, confidence, issueBackground?, remediationBackground?, issueDetail?, remediationDetail?, requestresponse*)>
<!ELEMENT serialNumber (#PCDATA)>
<!ELEMENT type (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT host (#PCDATA)>
<!ELEMENT path (#PCDATA)>
<!ELEMENT location (#PCDATA)>
<!ELEMENT severity (#PCDATA)>
<!ELEMENT confidence (#PCDATA)>
<!ELEMENT issueBackground (#PCDATA)>
<!ELEMENT remediationBackground (#PCDATA)>
<!ELEMENT issueDetail (#PCDATA)>
<!ELEMENT remediationDetail (#PCDATA)>
<!ELEMENT requestresponse (request?, response?)>
<!ELEMENT request (#PCDATA)>
<!ELEMENT response (#PCDATA)>
]>

The serialNumber element contains a long integer that is unique to that individual issue. If you export issues several times from the same instance of Burp, you can use the serial number to identify incrementally new issues.

The type element contains an integer which uniquely identifies the type of finding (SQL injection, XSS, etc.). This value is stable across different instances and builds of Burp.

The name element contains the corresponding descriptive name for the issue type.

The path element contains the URL for the issue (excluding query string).

The location element includes both the URL and a description of the entry point for the attack, where relevant (a specific URL parameter, request header, etc.).

The other elements, some of which are optional and can be selected by the user within the reporting wizard, are hopefully self-explanatory.

Now, edt, the clock is ticking for the Dradis function to import Burp Scanner issues!

P.S., IBurpExtenderCallbacks now has the following method, which you can use to shut down Burp programmatically:

public void exitSuite(boolean promptUser);

If the method returns, the user cancelled the shutdown prompt.

v1.2.16

Improved handling of AMF messages, to support some data types which were previously omitted.

v1.2.15

1. Burp Scanner now checks for a few new issues:

• XML external entity injection

• Server-side XML / SOAP injection

• Vulnerable Flash cross-domain policies

2. IBurpExtenderCallbacks gets a new method:

public IScanIssue[] getScanIssues(String urlPrefix);

This method returns all of the current scan issues for URLs matching the specified literal prefix. The prefix can be null to match all issues.

3. Previously, Burp Scanner could be configured to skip server-side injection checks for specific parameters. This feature is useful to avoid wasting time testing built-in platform parameters that are unlikely to contain vulnerabilities like SQL injection. Client-side issues like XSS are still checked for because this involves hardly any overhead.

Now, you can also configure Burp Scanner to skip absolutely all tests for specific parameters. This is useful if you know that a parameter is not used by the application, or if changing its value causes problems like session termination:

4. Various bugfixes.

v1.2.14

Adds AMF support to all tools except for Burp Intruder. Anywhere you see an HTTP request or response with an AMF-encoded body, Burp will display a tab containing a tree view of the decoded message:

If the message is editable, you can double-click individual nodes in the tree to modify their values, and Burp will reserialise the message with your new data. Burp supports all primitive data types, and also the array and hashmap data structures.

Burp Scanner is also updated to automatically place attack payloads within string-based AMF values.

v1.2.13

1. You can now pause and resume active scanning, using the context menu on the scan queue tab. A new status bar shows you whether the scanner is running, and the number of currently active scan threads.

2. There is a new task scheduler, which you can use to automatically start and stop certain tasks at defined times and intervals. You can schedule a task on a specific URL using the new context menu item that appears throughout Burp:

This action starts a wizard which lets you configure the details and timing of the task. The tasks currently implemented are shown below:

You can configure each task to be one-off, or to repeat at regular intervals. Tasks that you have created appear in a table in the suite Options tab. For example, the following configuration will begin scanning a target overnight at 2am, and suspend the scanner each day during working hours:

You can also create a new task, and edit or remove existing tasks, using the above buttons.

3. The extensibility method IBurpExtenderCallbacks.getParameters now returns the type of each parameter, as well as its name and value. The method's signature is unchanged, however the implementation now returns the following object for each parameter:

String[] { name, value, type }

4. Passwords are now masked on-screen in the UI for configuring www and proxy authentication.

v1.2.12

1. This release adds a new "find references" feature, which you can access via the context menus throughout Burp:

Anywhere you see an HTTP request, URL, domain, etc., you can use the "find references" function to search all of Burp's tools for HTTP responses which link to that item. When you view an individual search result, the response is automatically highlighted to show where the linking reference occurs:

Note that this feature treats the original URL as a prefix when searching for links, so if you select a host, you will find all references to that host; if you select a folder, you will find all references to items within that folder or deeper.

The new "find references" feature effectively serves the same purpose as the "linked from" list that existed in earlier versions of Burp Spider, but is much more powerful.

2. There is a new autosave feature, which saves a backup of Burp's state in the background at a configurable interval:

This setting persists across reloads of Burp. So you can configure Burp to always save its state to a local temp directory, and know that every time you use Burp you will have a backup copy of your work.

3. The HTTP message editor now has an option to URL-encode relevant characters as you type. If this option is turned on (via the context menu) then characters like & and = will be automatically replaced with their URL-encoded equivalents as you type:

4. The live active scanning feature has been modified to ignore requests for media resources (images, etc.) where the request does not contain any non-cookie parameters. Requests like these are virtually always for static resources which do not have any security significance, and so can be safely ignored by the scanner.

Note that despite this change to the live scanning feature, if you manually select items like these and send them for active scanning, then they will of course be scanned in the normal way.

v1.2.11

This release adds some new options to Burp Proxy for configuring the server SSL certificates that are presented to your browser. Use of these options can eliminate some SSL issues that arise when using an intercepting proxy:

• You can eliminate SSL alerts in your browser, and the need to create SSL exceptions in Firefox.

• Where web pages load SSL-protected items from other domains, you can ensure that these are properly loaded by the browser, without the need to first manually accept the proxy's SSL certificate for each referenced domain.

• You can work with thick client applications that refuse to connect to the server if an invalid SSL certificate is received.

The new options for handling server certificates can be configured individually for each proxy listener, and look like this:

These options are explained more fully below:

• use a self-signed certificate - This is the default option in previous releases of Burp. A simple self-signed SSL certificate is presented to your browser, which always causes an SSL alert.

• generate CA-signed per-host certificates - This is the new default option. Upon installation, Burp creates a unique, self-signed CA certificate, and stores this on your computer to use every time Burp is run. Each time you connect to an SSL-protected website, Burp generates a server certificate for that host, signed by the CA certificate. You can install Burp's CA certificate as a trusted root in your browser (see instructions below), so that the per-host certificates are accepted without any alerts.

• generate a CA-signed certificate with a specific hostname - This is similar to the preceding option, however Burp will generate a single host certificate to use with every SSL connection, using the hostname you specify. You should use this option if you are using invisible proxy mode with SSL connections - in this scenario, per-host certificates cannot be generated because the browser does not send a CONNECT request, and so the SSL negotiation precedes the receipt of the host information from the browser. The fixed host certificate is signed by Burp's CA certificate, which you can install in your browser (see instructions below), so that the host certificate is accepted without any alerts (provided you specify the correct hostname).

• use a custom certificate - This option was supported previously, and enables you to configure a specific certificate to present to your browser. This option should be used if the application uses a client which requires a specific server certificate (e.g. with a given serial number or certification chain). If the client simply requires a valid server certificate for the application domain, it is normally easier and quicker to use auto-generation of per-host certificates, as described above.

To make full use of Burp's CA-signed host certificates, you will need to install Burp's CA certificate as a trusted root in your browser. Note: If you install a trusted root certificate in your browser, then an attacker who has the private key for that certificate may be able to man-in-the-middle your SSL connections without obvious detection, even when you are not using an intercepting proxy. To protect against this, Burp generates a unique CA certificate for each installation, and the private key for this certificate is stored on your computer, in a platform-dependent location. If untrusted people can read local data on your computer, you may not wish to install Burp's CA certificate.

To install Burp's CA certificate on IE, perform the following steps:

1. If you have previously installed a different CA certificate generated by Burp, you should first remove it (see instructions below).

2. Configure your browser to use Burp as its proxy, and configure Burp's proxy listener to generate CA-signed per-host certificates.

3. Visit any SSL-protected URL. If you receive a warning, click "Continue to this website (not recommended)".

4. Click on the "Certificate error" button in the address bar.

5. Click "View certificates".

6. Go to the "Certification Path" tab.

7. Select the root certificate in the tree (PortSwigger CA).

8. Click "View Certificate".

9. Click "Install Certificate".

10. In the Certificate Import Wizard, select "Place all certificates in the following store".

11. Click "Browse".

12. Select "Trusted Root Certification Authorities".

13. Click "OK".

14. Complete the wizard.

15. Click "Yes" on the security warning.

16. Close all dialogs and restart IE.

If everything has worked, when you visit SSL-protected URLs using Burp you should see a valid certificate chain:

To remove a Burp CA certificate which you have previously installed on IE, perform the following steps:

1. Go to Tools Internet Options.

2. Go to the Content tab.

3. Click "Certificates".

4. Go to the Trusted Root Certification Authorities tab.

5. Select the PortSwigger CA entry in the list.

6. Click "Remove".

7. Click "Yes" in each confirmation dialog.

8. Confirm that the PortSwigger CA entry has been removed.

9. Restart IE.

To install Burp's CA certificate on Firefox, perform the following steps:

1. If you have previously installed a different CA certificate generated by Burp, you should first remove it (see instructions below).

2. Configure your browser to use Burp as its proxy, and configure Burp's proxy listener to generate CA-signed per-host certificates.

3. Visit any SSL-protected URL.

4. On the "Secure Connection Failed" screen, click on "Or you can add an exception", and then click "Add Exception".

5. Click "Get Certificate", then click "View".

6. Select the root certificate in the tree (PortSwigger CA).

7. Click "Export" and save the certificate somewhere.

8. Click "Close" on the Certificate Viewer dialog, and "Cancel" on the "Add Security Exception" dialog.

9. Go to Tools Options.

10. Click "Advanced".

11. Go to the Encryption tab.

12. Click "View Certificates".

13. Go to the Authorities tab.

14. Click "Import" and select the certificate file that you previously saved.

15. On the "Downloading Certificate" dialog, check the box "Trust this CA to identify web sites", and click "OK".

16. Close all dialogs and restart Firefox.

If everything has worked, when you visit SSL-protected URLs using Burp you should see a valid certificate chain:

To remove a Burp CA certificate which you have previously installed on Firefox, perform the following steps:

1. Go to Tools Options.

2. Click "Advanced".

3. Go to the Encryption tab.

4. Click "View Certificates".

5. Go to the Authorities tab.

6. Select the PortSwigger CA entry in the list (this is a sub-entry under PortSwigger).

7. Click "Delete".

8. Click "OK" in the confirmation dialog.

9. Confirm that the PortSwigger CA entry has been removed.

10. Restart Firefox.

Thanks are due to Rogan Dawes of WebScarab fame for prompting me to add this feature and sharing some sample code for implementing it.