Burp Scanner Help

8/7/2019 Burp Scanner Help

1/20

Burp Scanner Help

1/25/2011

Halil OZTURKCI


2/20

1 | P a g e

What is Burp Scanner?

Burp Scanner is a tool for performing automated discovery of security vulnerabilitiesin 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 andsemi-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:

y Active scanning - The scanner sends various crafted requests to the application,derived from a base request, and analyses the resulting responses look ing for

vulnerable behaviour.

y Passive scanning - The scanner doesn't send any new requests of its own; itmerely 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:

y Manual scanning - You can send one or more requests from other Burp tools, toperform active or passive scans against those specific requests.

y Live scanning as you browse - You can configure the Scanner to automaticallyperform 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:

y Being able to perform quick and reliabl e scans for many common vulnerabilities on aper-request basis can hugely reduce your testing effort, enabling you to direct your

human expertise towards vulnerabilities whose detection cannot be reliably

automated.

y Results from each type of scan are displayed immediately, and can directly informyour other testing actions in relation to the individual requests involved.

y Burp avoids a frustrating problem with other scanners, in which a monolithicautomated scan takes an age to complete, with little assuranc e over whether the

scan has worked, or whether it encountered problems that impacted on its

effectiveness.


3/20

2 | P a g e

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 scanningIn this mode of scanning, Burp takes an individual request to the application, called

the "base request", and modifies i t 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 scann ing.

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, OScommand 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


4/20

3 | P a g e

preceding checks, Burp effectively emulates the actions that a skilled and methodical

human tester would perform. The only bugs that B urp 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, becausein 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. Neverthel ess, 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 appl ication - 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:

y Clear-text submission of passwords.y Insecure cookie attributes, like missing HttpOnly and secure flags.y Liberal cookie scope.y Cross-domain script includes and Referer leakage.y Forms with autocomplete enabled.y Caching of SSL-protected content.y Directory listings.y Submitted passwords returned in later responses.y Insecure transmission of session tokens.y Leakage of information like internal IP addresses, email addr esses, stack traces, etc.y Insecure ViewState configuration.y 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.


5/20

4 | P a g e

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:

y Because passive scans don't send any new requests to the application, you canperform them safely against critical production applications where you want total

control of every request that you send.

y Some applications are aggressive in reacting to attacks, by termina ting your sessionor 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 causi ng any

problems.

y If you don't (yet) have authorisation to attack a target, you can use passive scanningto identify vulnerabilities purely by browsing the application as a normal user. Forexample, if you are proposing for a new penetration testing engagem ent, 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 justthis request using the context menu:


6/20

5 | P a g e

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:


7/20

6 | P a g e

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 potenti ally 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:


8/20

7 | P a g e

The wizard then completes and the selected items are sent for scanning in the usual

way.

Live scanning

Afurther 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:


9/20

8 | P a g e

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 ind icates its progress - the number of


10/20

9 | P a g e

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:


11/20

10 | P a g e

You can use the context menu on the scan queue to perform various actions:y Show the details of the selected item.y Cancel the selected item(s).y Scan the selected item(s) again.y 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:


12/20

11 | P a g e

Where multiple issues have been found of the same type, these are aggregated intoa 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:

y The request parameter in which the attack input is supplied (SearchTerm).y The synactic context in which the input is returned in the response (within a piece of

JavaScript, in a single-quote-delimited string).

y That the application escapes any single quote characters in our input, but fails toescape the backslash, allowing us to circumvent the filter.

y The exact proof-of-concept payload which Burp submitted to the application, and theform in which this payload was returned.


13/20

12 | P a g e

y That the original request used the POST meth od, and Burp was able to convert thisto 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:


14/20

13 | 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 issue s

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.


15/20

14 | 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 wi thin HTTP requests will have attacks

placed into them:

y The values of URL, body and cookie parameters.y 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.

y HTTP headers - if selected, Burp places attacks into the User-Agent and Refererheaders, often detecting issues like SQL injection or persistent XSS within logging

functionality.

y AMF string parameters - For requests in Action Message Format, Burp places attacksinto any string-based data types within the message.

y REST-style URL parameters - if selected, Burp places attacks into each directory orfile 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


16/20

15 | 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 selecti on". 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 thatdon'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


17/20

16 | 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,


18/20

17 | 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:

y The reporting format (screen- or printer-friendly).y The level of issue description and remediation to include.y Whether to show request and response details in f ull, or as extracts, or not at all.y The categories of discovered issues to include or exclude.y Whether to organise issues by type, severity or URL.y 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:


19/20

18 |P a g e


20/20

19 | 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:

remediationBackground?, issueDetail?, remediationDetail?, requestresponse*)>

]>

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.

Documents

Burp Scanner Help