Xx_Menu
- Scanner
- Issue activity
- Scan queue
- Live scanning
- Issue definition
- Options - Intruder
- Target
- Positions
- Payloads
- Options
Ax_Scanner
Using the step
- z.Confirm agent settings.
- y.Intercept on> request domain > Intercept off > go to Target site map look scope
Or~
- x.Auto scan method
- w.Send to the Burp Repeater module to verify the vulnerability
- v.Output report
Bx_Scanning mode
Active Scanning and Passive 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 behavior that indicates the presence of various vulnerabilities. These modified requests are sent to the application, and the resulting responses are analyzed. In many cases, further requests will be sent, based on the results of the initial probes.
Note: 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 that automated scanning may have on the application and its data. Ideally, 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 are 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:
Input-based vulnerabilities targeting the client side, such as cross-site scripting, HTTP header injection, and open redirection.
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 behaviors 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 kinds of issues that are difficult or laborious for a human tester to diagnose.
In this mode of scanning, Burp doesn't send any new requests to the application - it merely analyzes 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 authorized 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 over 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 authorization 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.
Cx_Scanner options
omit..
Dx_Scanner control
Ex_Intruder
be continue.