Class: Buby::ScannerCheck
- Includes:
- Java::Burp::IScannerCheck
- Defined in:
- lib/buby/scanner_check.rb
Overview
DSL methods
Extensions can implement this interface and then call #registerScannerCheck to register a custom Scanner check. When performing scanning, Burp will ask the check to perform active or passive scanning on the base request, and report any Scanner issues that are identified.
Constant Summary collapse
- REPORT_EXISTING =
-1
- REPORT_BOTH =
0
- REPORT_NEW =
1
Instance Method Summary collapse
-
#consolidateDuplicateIssues(existingIssue, newIssue) ⇒ Object
abstract
The Scanner invokes this method when the custom Scanner check has reported multiple issues for the same URL path.
-
#doActiveScan(baseRequestResponse, insertionPoint) ⇒ Array<IScanIssue>?
abstract
The Scanner invokes this method for each insertion point that is actively scanned.
-
#doPassiveScan(baseRequestResponse) ⇒ Array<IScanIssue>?
abstract
The Scanner invokes this method for each base request / response that is passively scanned.
Instance Method Details
#consolidateDuplicateIssues(existingIssue, newIssue) ⇒ Object
subclass and override to proccess scan issues
The Scanner invokes this method when the custom Scanner check has reported multiple issues for the same URL path. This can arise either because there are multiple distinct vulnerabilities, or because the same (or a similar) request has been scanned more than once. The custom check should determine whether the issues are duplicates. In most cases, where a check uses distinct issue names or descriptions for distinct issues, the consolidation process will simply be a matter of comparing these features for the two issues.
79 80 81 82 |
# File 'lib/buby/scanner_check.rb', line 79 def consolidateDuplicateIssues(existingIssue, newIssue) pp [:got_consolidateDuplicateIssues, existingIssue, newIssue] REPORT_BOTH end |
#doActiveScan(baseRequestResponse, insertionPoint) ⇒ Array<IScanIssue>?
subclass and call super
Extensions are responsible for ensuring that attack payloads are suitably encoded within requests (for example, by URL-encoding relevant metacharacters in the URL query string). Encoding is not automatically carried out by the IScannerInsertionPoint
, because this would prevent Scanner checks from testing for certain input filter bypasses. Extensions should query the IScannerInsertionPoint
to determine its type, and apply any encoding that may be appropriate.
The Scanner invokes this method for each insertion point that is actively scanned. Extensions may issue HTTP requests as required to carry out active scanning, and should use the IScannerInsertionPoint
object provided to build scan requests for particular payloads.
55 56 57 58 59 60 |
# File 'lib/buby/scanner_check.rb', line 55 def doActiveScan(baseRequestResponse, insertionPoint) pp [:got_doActiveScan, baseRequestResponse, insertionPoint] if $DEBUG Buby::HttpRequestResponseHelper.implant baseRequestResponse Buby::Implants::ScannerInsertionPoint.implant insertionPoint nil end |
#doPassiveScan(baseRequestResponse) ⇒ Array<IScanIssue>?
subclass and call super
Extensions should not only analyze the HTTP messages provided during passive scanning, and should not make any new HTTP requests of their own.
The Scanner invokes this method for each base request / response that is passively scanned.
28 29 30 31 32 |
# File 'lib/buby/scanner_check.rb', line 28 def doPassiveScan(baseRequestResponse) pp [:got_doPassiveScan, baseRequestResponse] if $DEBUG Buby::HttpRequestResponseHelper.implant baseRequestResponse nil end |