Burp Scanner - Reporting
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, 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-formtatted 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:
- The serialNumber element 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.
- The type element 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.
- The name element contains the corresponding descriptive name for the issue
type. See the list of scan issue types for
a list of all issue names.
- 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,
- The request and
response elements have a
base64 attribute, which
contains a Boolean value indicating whether the messages have been
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
- Remediation detail - For some types of issues, this
contains further remediation advice, reflecting the particular features
of the issue that were observed.
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.
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.
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
- The severities of issue to include in the summary table and bar
Thursday, September 8, 2016
This release introduces a new scan check for second-order SQL injection vulnerabilities. In situations where Burp observes stored user input being returned in a response, Burp Scanner now performs its usual logic for detecting SQL injection, with payloads supplied at the input submission point, and evidence for a vulnerability detected at the input retrieval point.
See all release notes ›