Interface ActiveScanCheck

public interface ActiveScanCheck
Extensions can implement this interface, then call Scanner.registerActiveScanCheck(ActiveScanCheck, ScanCheckType) to register a custom active scan check. During an audit, Burp invokes the check to perform an active audit on the base request according to the specified ScanCheckType. Burp reports any audit issues that are identified.

  • Method Details

    • checkName

      String checkName()
      The name Burp will use to identify this scan check.
      Returns:
      Name of the scan check.

    • doCheck

      AuditResult doCheck(HttpRequestResponse baseRequestResponse, AuditInsertionPoint insertionPoint, Http http)
      The Scanner invokes this method according to the registered ScanCheckType. Use the Http object to issue HTTP requests during an active audit. Use the AuditInsertionPoint object to build requests with specific payloads. Note: Scan checks should submit non-encoded payloads to insertion points. The insertion point should handle any necessary encoding based on its type and location.
      Parameters:
      baseRequestResponse - The base HttpRequestResponse that should be actively audited.
      insertionPoint - An AuditInsertionPoint object. This can be queried to obtain details of the insertion point being tested. It can also be used to build requests for particular payloads. Note: This object is only available if the scan check is registered with the ScanCheckType.PER_INSERTION_POINT type. For other types, a AuditInsertionPoint object is returned, but it only contains placeholder data.
      http - A Http object. This can be used to send and retrieve HTTP requests within the custom scan check. Any requests you send are automatically linked to the current scan task.
      Returns:
      An AuditResult object that contains a list of AuditIssue objects, or an empty AuditResult object if no issues are identified.

    • consolidateIssues

      default ConsolidationAction consolidateIssues(AuditIssue existingIssue, AuditIssue newIssue)
      The Scanner invokes this method when the custom Scan 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.
      Parameters:
      existingIssue - An AuditIssue that was previously reported by this Scan check.
      newIssue - An AuditIssue at the same URL path that has been newly reported by this Scan check.
      Returns:
      A ConsolidationAction to determine which issue(s) should be reported in the main Scanner results.