• Download
• Buy
• Help
• Forum
• Blog
• Contact
• Login

• Home
• >Burp
• >Help
• >Scanner

Burp Scanner Help

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.

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

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:

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:

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:

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

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:

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.
• 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:

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.

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 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 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.

You can configure whether the scanner should follow redirections where this is necessary to identify certain vulnerabilities (for example echoed input or a database error message which is only displayed when a redirect is followed).

Because some applications issue redirects to third-party URLs which include parameter values that you have submitted, Burp protects you against inadvertently attacking third-party applications, by not following just any redirection which is received. If the request being scanned is within the defined target scope (i.e. you are using target scope to control what gets scanned), then Burp will only follow redirects that are within that scope. If the request being scanned is not in scope (i.e. you have manually initiated a scan of an out-of-scope request), Burp will only follow redirects which (a) are to the same host/port as the request being scanned; and (b) are not explicitly covered by a scope exclusion rule (e.g. "logout.aspx").

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

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:

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.

Copyright © 2010 PortSwigger Ltd. All rights reserved.

• Company
• Legal
• Contact