Burp Scanner Help

Halil OZTURKCI
 What is Burp Scanner?
Burp Scanner is a tool for performing automated discovery of security vulnerabilities
in web applications. It is designed to be used by penetration testers, and to fit in
closely with your existing techniques and methodologies for performing manual and
semi-automated penetration tests of web applications.

Using most web scanners is a detached exercise: you provide a start URL, click "go",
and watch a progress bar update until the scan is finished and a report is produced.
Using Burp Scanner is very different, and is much more tightly integrated with the
actions you are already carrying out when attacking an application, giving you fine-
grained control over each request that gets scanned, and direct feedback about the
results.

Burp Scanner can perform two types of scans:

 Active scanning - The scanner sends various crafted requests to the

application, derived from a base request, and analyses the resulting responses
looking for vulnerable behaviour.
 Passive scanning - The scanner doesn't send any new requests of its own; it
merely analyses the contents of existing requests and responses, and deduces
vulnerabilities from those.

You can initiate scans against your target application in two different ways:

 Manual scanning - You can send one or more requests from other Burp
tools, to perform active or passive scans against those specific requests.
 Live scanning as you browse - You can configure the Scanner to
automatically perform active or passive scans against requests passing through the
Proxy as you are browsing the application.

This approach to automated vulnerability detection brings a number of benefits to

the penetration tester:

 Being able to perform quick and reliable scans for many common
vulnerabilities on a per-request basis can hugely reduce your testing effort, enabling
you to direct your human expertise towards vulnerabilities whose detection cannot
be reliably automated.
 Results from each type of scan are displayed immediately, and can directly
inform your other testing actions in relation to the individual requests involved.
 Burp avoids a frustrating problem with other scanners, in which a monolithic
automated scan takes an age to complete, with little assurance over whether the
scan has worked, or whether it encountered problems that impacted on its
effectiveness.

1|Page
 By controlling exactly what gets scanned, and by monitoring in real time both the
scan results and the wider effects on the application, Burp Scanner lets you combine
the virtues of reliable automation with intuitive human intelligence, often with
devastating results.

Active scanning
In this mode of scanning, Burp takes an individual request to the application, called
the "base request", and modifies it in various ways designed to trigger behaviour
that indicates the presence of various vulnerabilities. These modified requests are
sent to the application, and the resulting responses are analysed. In many cases,
further requests will be sent, based on the results of the initial probes.

This mode of operation generates large numbers of requests which are malicious in
form and which may result in compromise of the application. You should use this
scanning mode with caution, only with the explicit permission of the application
owner, and having warned them of the possible effects which automated scanning
may have on the application and its data. If possible, scanning should be performed
against non-production systems, and full backups performed prior to scanning.

There are various well-known limitations on the types of vulnerabilities within web
applications whose detection can be reliably automated. Burp's active scanning
capabilities were designed to focus on the kind of input-based bugs that
scanners can reliably look for. By avoiding the false positives that arise in other
areas, Burp gives you confidence in its output, leaving you to focus on the aspects of
the job that require human experience and intelligence to deliver.

The issues that Burp's active scanning is able to identify mostly fall into two
categories:

1. Input-based vulnerabilities targeting the client side, such as cross-site

scripting, HTTP header injection, and open redirection.
2. Input-based vulnerabilities targeting the server side, such as SQL injection,
OS command injection, and file path traversal.

Issues in category 1 can be detected with a very high degree of reliability. In most
cases, everything that is relevant to finding the bug is visible on the client side. For
example, to detect reflected XSS, Burp Scanner submits some benign input in each
entry point to the application, and looks for this being echoed in responses. If it is
echoed, Burp then parses the response content to determine the context(s) in which
the echoed input appears. It then supplies various modified inputs to determine
whether strings that constitute an attack in those contexts are also echoed. Burp
Scanner has knowledge of the wide range of broken input filters, and associated
bypasses, that arise with web applications, and it checks for all that apply to the
context. By implementing a full decision tree of checks, driven by feedback from

2|Page
 preceding checks, Burp effectively emulates the actions that a skilled and methodical
human tester would perform. The only bugs that Burp should miss are those with
some unusual feature requiring intelligence to understand, such as a custom scheme
for encapsulating inputs.

Issues in category 2 are inherently less amenable to automated detection, because

in many cases the behaviours that are relevant to identifying the bugs occur only on
the server, with little manifestation on the client side. For example, SQL injection
bugs may return verbose database errors in responses, or they may be fully blind.
Burp Scanner employs various techniques to identify blind server-side injection
issues, by inducing time delays, changing Boolean conditions and performing fuzzy
response diffing, etc. These techniques are inherently more error prone than the
methods that are available in category 1. Nevertheless, Burp Scanner achieves a
high success rate in this area, reliably reporting numerous kind of issue that are
difficult or laborious for a human tester to diagnose.

Passive scanning
In this mode of scanning, Burp doesn't send any new requests to the application - it
merely analyses the contents of existing requests and responses, and deduces
vulnerabilities from those. This mode of operation can be used safely and legally in
any situation in which you are authorised to access the application.

Burp Scanner is able to identify numerous kind of vulnerabilities using solely passive
techniques, including:

 Clear-text submission of passwords.

 Insecure cookie attributes, like missing HttpOnly and secure flags.
 Liberal cookie scope.
 Cross-domain script includes and Referer leakage.
 Forms with autocomplete enabled.
 Caching of SSL-protected content.
 Directory listings.
 Submitted passwords returned in later responses.
 Insecure transmission of session tokens.
 Leakage of information like internal IP addresses, email addresses, stack
traces, etc.
 Insecure ViewState configuration.
 Ambiguous, incomplete, incorrect or non-standard Content-type directives.

Many of these issues are relatively unexciting, and recording them is dull and
repetitive for a human. But as penetration testers we are obliged to report them.

3|Page
 Having Burp Scanner reliably mop up these issues as you browse an application is a
time and sanity saver.

Being able to carry out passive-only vulnerability scanning is beneficial in a range of

situations:

 Because passive scans don't send any new requests to the application, you
can perform them safely against critical production applications where you want total
control of every request that you send.
 Some applications are aggressive in reacting to attacks, by terminating your
session or locking your account every time an apparently malicious request is
received. In this situation, you may be restricted to piecemeal manual testing, but
you can still use passive scanning to identify various kinds of issues without causing
any problems.
 If you don't (yet) have authorisation to attack a target, you can use passive
scanning to identify vulnerabilities purely by browsing the application as a normal
user. For example, if you are proposing for a new penetration testing engagement,
you can passively scan your target to get a feel for its security posture, and hopefully
get some reportable issues in the bag before you even begin the official testing.

Initiating scans
Manual scanning
From anywhere within Burp Suite, you can select one or more HTTP requests, and
send these to the Scanner to perform active or passive scanning. For example, if you
intercept an interesting request using Burp Proxy, you can initiate a scan against just
this request using the context menu:

4|Page
Similarly, you can select sets of requests from within the Target site map or Proxy
history, and send these in bulk to the Scanner. So, after browsing around an
application and building up a comprehensive map of its content, you can tell Burp to
scan specific areas of the application's functionality:

5|Page
If you select multiple items and send these for active scanning, Burp launches a brief
wizard which lets you fine-tune your selection. The first screen of the wizard offers
you various intuitive filters to remove potentially unnecessary items (duplicates,
already scanned items, media content, etc.), and shows you how many items will be
affected by each filter:

The second screen of the wizard shows you a list of the remaining items, and lets
you sort the table by various relevant properties, view the full requests and
responses, and delete individual items:

6|Page
The wizard then completes and the selected items are sent for scanning in the usual
way.

Live scanning
A further way to initiate scans is to use the "live scanning" feature. In this mode, you
tell Burp what your target scope is for active and passive scanning, and it will
automatically initiate active or passive scans against relevant requests as you use
the application. When operating in this mode, you simply need to browse around the
application as a normal user, to show Burp where the application's content and
functionality are, and it will work away in the background to find vulnerabilities for
you.

When using live scanning, you have fine-grained control over the requests that Burp
will automatically scan. If you have already configured a suite-wide target scope for
your current work, then you can simply tell Burp to scan every request that falls
within that scope. Alternatively, you can define a custom scope to use for active and
passive scanning. In the example below, Burp has been configured to actively scan
every request that is made to www.myapp.com, with the exception of login requests,
and to passively scan every request that is made to any destination whatsoever:

7|Page
Note that the live scanning feature ignores 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. (This does not apply to
manual scanning - if you manually select items like these and send them for active
scanning, then they will of course be scanned in the normal way.)

Active scan queue

When you send requests for passive scanning, these are processed immediately.
Because active scans involve sending large numbers of requests to the server,
requests sent for active scanning may be queued up. A typical request with a dozen
parameters will be scanned in a minute or two, and the scan queue is processed by a
configurable thread pool, so the number of waiting items rarely grows very large. As
each item is scanned, the scan queue table indicates its progress - the number of

8|Page
requests made, the percentage complete, and the number of vulnerabilities
identified. This last value is colourised according to the significance and confidence
attached to the most serious issue:

You can double-click any item in the scan queue to display the issues identified so
far, and view the base request and response for that item:

9|Page
 You can use the context menu on the scan queue to perform various actions:

 Show the details of the selected item.

 Cancel the selected item(s).
 Scan the selected item(s) again.
 Pause or resume the scanner.

Used in the ways described, Burp Scanner gives you fine-grained control over
everything that it does, and integrates closely with your other testing activities. It
lets you prioritise areas of an application that interest you, by browsing them using
live scanning, or selecting them for scanning from the site map. And it provides
immediate feedback about those areas to inform your manual testing actions.

Reviewing results
In addition to the per-request view of discovered issues shown above, Burp Scanner
maintains a central record of all the issues it has discovered, organised in a tree view
of the target application's site map. Selecting a host or folder in the tree shows a
listing of all the issues identified for that branch of the site:

10 | P a g e
 Where multiple issues have been found of the same type, these are aggregated into
a single item in the top-right panel. You can expand the aggregated item to view
each individual instance of the issue. Selecting an issue in the top-right panel shows
the full detail for that issue in the bottom-right panel. This includes a customised
vulnerability advisory, and the full requests and responses that are relevant to
understanding and reproducing the issue.

The advisory includes a standard description of the issue and its remediation, and
also a description of any specific features that apply to the issue and affect its
remediation. In the example above, the cross-site scripting advisory tells us:

 The request parameter in which the attack input is supplied (SearchTerm).

 The synactic context in which the input is returned in the response (within a
piece of JavaScript, in a single-quote-delimited string).
 That the application escapes any single quote characters in our input, but fails
to escape the backslash, allowing us to circumvent the filter.
 The exact proof-of-concept payload which Burp submitted to the application,
and the form in which this payload was returned.

11 | P a g e
 That the original request used the POST method, and Burp was able to
convert this to a GET request to facilitate demonstration and exploitation of the
issue.

Every issue that Burp Scanner reports is given a rating both for severity (high,
medium, low, informational) and for confidence (certain, firm, tentative). When an
issue has been identified using a less reliable technique, Burp makes you aware of
this, by dropping the confidence level.

Alongside the advisory, Burp shows the requests and responses that were used to
identify the issue, with relevant portions highlighted. You can review these to see
how Burp identified the issue, and quickly understand the nature of the vulnerability.
You can also send the request directly to other tools to manually verify the issue, or
fine-tune the proof-of-concept attack that was generated by Burp:

12 | P a g e
Within the list of scan issues, you can modify the severity and confidence levels of
individual or multiple issues (via the context menu), or delete issues altogether (via
the context menu or using the 'del' key).

Note that if you delete an issue, and Burp rediscovers the same issue (for example, if
you rescan the same request), the issue will be reported again. If instead you mark
the issue as a false positive, then this will not happen. Therefore, deletion of issues
is best used for cleaning up the Results tree to remove hosts or paths you are not
interested in. For unwanted issues within the functionality you are still working on,
you should use the false positive flag.

Scan optimisation
Burp Scanner gives you detailed information in real time about all of the actions it is
performing. In the scan queue, you can monitor the progress of each individual base
request that is being scanned. The table shows you the number of "insertion points"
where Burp is placing payloads, and the number of attack requests that have been
generated. (The latter is not a linear function of the former - observed application
behaviour feeds back into subsequent attack requests, just as it would for a human
tester.)

This information lets you quickly see whether any of your scans are progressing too
slowly, and understand the reasons why. Given this information, you can then take
action to optimise your scans. Within the scan queue, there is a context menu which
lets you cancel or re-prioritise individual items. Within the Options tab, you can also
optimise the scanner configuration based on what you have learnt about the
application, using the options described below.

13 | P a g e
 Attack insertion points
A key factor in the speed and effectiveness of scans is the selection of attack
insertion points. Burp gives you fine-grained control over the locations within the
base request where attack payloads will be placed, using the following configuration
options:

The checkboxes let you define which locations within HTTP requests will have attacks
placed into them:

 The values of URL, body and cookie parameters.

 Parameter name - if selected, Burp adds an additional parameter to the
request and places attacks into the name of this parameter, often detecting unusual
bugs that are missed if only parameter values are tested.
 HTTP headers - if selected, Burp places attacks into the User-Agent and
Referer headers, often detecting issues like SQL injection or persistent XSS within
logging functionality.
 AMF string parameters - For requests in Action Message Format, Burp places
attacks into any string-based data types within the message.
 REST-style URL parameters - if selected, Burp places attacks into each
directory or file name within the path portion of the URL.

You can also set a limit on the number of insertion points that Burp will attack within
each base request. Occasionally, HTML forms may contain an excessive number of
fields (hundreds, or more). If Burp performed a full vulnerability scan of every field,
the scan would take an excessive amount of time to complete. Setting a limit on
insertion points prevents your scans from becoming stalled if they encounter forms
with huge numbers of parameters. When this limit is applied, the item's entry in the
scan queue will indicate the number of insertion points that were skipped, enabling

14 | P a g e
you to manually review the base request and decide if it is worth performing a full
vulnerability scan of all its possible entry points.

You can tell Burp to use "intelligent attack selection". This option causes Burp to
perform or omit each type of server-side check based on the base value of each
attack insertion point. For example, if a parameter's value contains characters that
don't normally appear in filenames, Burp will skip file path traversal checks for this
parameter. Using this option can considerably speed up your scans, with minimal risk
of missing actual vulnerabilities that exist.

The insertion point configuration lets you specify request parameters for which Burp
should skip server-side injection checks. These checks are relatively time-consuming,
because Burp sends multiple requests probing for various blind vulnerabilities on the
server. If you believe that certain parameters appearing within requests are not
vulnerable (for example, built-in parameters used only by the platform or web
server), you can tell Burp not to test these. (Note that client-side checks like cross-
site scripting are always performed because testing each request parameter imposes
minimal overhead on the duration of the scan if the parameter is non-vulnerable.)

You can identify REST parameters by their position (slash-delimited) within the URL
path, as well as by their value. To do this, select "REST parameter" from the
parameter drop-down, "name" from the item drop-down, and specify the index
number (1-based) of the position within the URL path which you wish to exclude
from testing.

You can also configure any parameters for which Burp should not perform any checks
whatsoever.

It is possible to specify fully customisable attack insertion points for active scanning,
so you can specify arbitrary locations within a base request where attack strings
should be placed. To use this function, send the relevant base request to Intruder,
use the payload positions UI to define the start/end of each insertion point in the

15 | P a g e
usual way, and select the Intruder menu option "actively scan defined insertion
points".

Active scanning engine

These options let you fine-tune Burp's scan engine, depending on the performance
impact on the application, and on your own processing power and bandwidth. If you
find that your scans are running slowly, but the application is performing well and
your own CPU utilisation is low, you can increase the number of scan threads to
make your scans proceed faster. If you find that connection errors are occurring,
that the application is slowing down, or that your own computer is locking up, you
should reduce the thread count, and maybe increase the number of retries on
network failure and the pause between retries. If the functionality of the application
is such that actions performed on one base request interfere with the responses
returned from other requests, you should consider reducing the thread count to 1, to
ensure that only a single base request is scanned at a time.

If you wish to avoid overloading the application, or to remain stealthy from a

network perspective, you can use the throttle settings to add fixed or random
intervals between requests.

Active scanning areas

These options let you define which checks are performed during active scanning.
Each check that is performed increases the number of requests made, and the
overall time of each scan. You can turn individual checks on or off, based on your
knowledge of an application's technologies, or on how rigorous you require your
scans to be. For example, if you know that an application does not use any LDAP,

16 | P a g e
 you can turn off LDAP injection tests. Or you can configure Burp to do a quick once-
over of an application, checking only for XSS and SQL injection in URL and body
parameters, before returning later to carry out more comprehensive testing of every
vulnerability type in every insertion point.

Passive scanning areas

Passive scans do not send any requests of their own, and each passive check
imposes a negligible processing load on your computer. Nevertheless, you can
disable individual areas of checks if you are simply not interested in them and don't
want them appearing within scan results.

Reporting
When you have finished testing, you can export a report of all or selected issues in
HTML format. To do this, select the desired issues from the aggregated results
display (you can multi-select individual hosts, folders, issues, etc.) and select "report
issues" from the context menu. The reporting wizard lets you choose various options
for your report, including:

 The reporting format (screen- or printer-friendly).

 The level of issue description and remediation to include.
 Whether to show request and response details in full, or as extracts, or not at
all.
 The categories of discovered issues to include or exclude.
 Whether to organise issues by type, severity or URL.
 Report title, heading levels, etc.

The report for the cross-site scripting vulnerability shown previously, with all detail
turned on, and showing extracts of application responses in printer-friendly format,
looks like this:

17 | P a g e
18 | P a g e
You can also report issues in XML format, to enable easy integration with other tools.
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.

19 | P a g e