Reporting scan results
You can export a report of some or all of the issues generated by Burp Scanner. To do this, select the desired issues in the Issues view of the Site map, or in the issue activity log, and choose "Report selected issues" from the context menu. The reporting wizard lets you choose various options for your report, as described below.
You can choose one of the following formats for the report:
- HTML - This produces an HTML-formatted report for printing or viewing in a browser.
- XML - This produces an XML-formatted report suitable for importing into other tools or reporting frameworks. You can optionally Base64-encode HTTP requests and responses within the XML output. Since HTTP messages may contain nonprinting characters which are not strictly permitted within XML documents (even in CDATA blocks), using this option is preferable because it ensures compatibility with strict XML parsers.
Note: The XML format uses an internal DTD, and authors of interoperability code are recommended to review a sample report to obtain the current DTD. The following XML elements are worth noting:
serialNumberelement contains a long integer that is unique to that individual issue instance. If you export issues several times from the same instance of Burp, you can use the serial number to identify incrementally new issues.
typeelement contains an integer that uniquely identifies the issue type (SQL injection, XSS, etc.). This value is stable across different instances of Burp. See the list of scan issue types for a list of all numeric type identifiers.
nameelement contains the corresponding descriptive name for the issue type. See the list of scan issue types for a list of all issue names.
pathelement contains the URL for the issue (excluding query string).
locationelement includes both the URL and a description of the entry point for the attack, where relevant (a specific URL parameter, request header, etc.).
responseelements have a
base64attribute, which contains a Boolean value indicating whether the messages have been Base64-encoded.
You can choose the types of details to include in the report:
- Issue background - This is the standard description of the issue, and is the same for all issues of the same type.
- Remediation background - This is the standard remediation advice, and is the same for all issues of the same type.
- Issue detail - For some types of issues, this contains some further custom information about the particular issue, drawing attention to specific details that apply to the instance of the issue.
- Remediation detail - For some types of issues, this contains further remediation advice, reflecting the particular features of the issue that were observed.
- Vulnerability classifications - This contains the relevant mappings to the Common Weakness Enumeration (CWE) list.
You can choose how HTTP messages should appear in the report. The following options are available for requests and responses:
- Do not include - The report will not contain any messages of the relevant type.
- Include relevant extract - The report will include the parts of the message that are highlighted in the in-tool results, and enough of the surrounding message to give context.
- Include in full - The report will include the full messages, including parts that are not directly relevant to understanding or reproducing the issue. Optionally, you can limit each message to a specified maximum length, to prevent the report from ballooning in size in the case of any excessively large messages.
Selecting issue types
The wizard lists the different types of issues that were included in your selection, and a count of the number of instances of each type. You can deselect any types of issues that you do not wish to include. This is useful if you have selected a large number of issues (for example, by selecting the application host), and want to remove certain less interesting types of issues from the report.
You can specify the file where the report will be saved.
For HTML reports, you can specify the following details:
- Report title.
- How issues should be organized within the report (by type, severity, or URL).
- The number of levels of detail to include in the table of contents.
- The severities of issue to include in the summary table and bar chart.