Package burp.api.montoya.scanner

Interface ScanCheck

  • public interface ScanCheck
    Extensions can implement this interface and then call Scanner.registerScanCheck(ScanCheck) to register a custom Scanner check. When performing an audit, Burp will ask the check to perform an active or passive audit on the base request, and report any audit issues that are identified.

    • Method Detail

      • activeAudit

        java.util.List<AuditIssue> activeAudit​(HttpRequestResponse baseRequestResponse,
                                       AuditInsertionPoint auditInsertionPoint)
        The Scanner invokes this method for each insertion point that is actively audited. Extensions may issue HTTP requests as required to carry out an active audit, and should use the AuditInsertionPoint object provided to build requests for particular payloads. Note: Scan checks should submit raw non-encoded payloads to insertion points, and the insertion point has responsibility for performing any data encoding that is necessary given the nature and location of the insertion point.
        Parameters:
        baseRequestResponse - The base HttpRequestResponse that should be actively audited.
        auditInsertionPoint - An AuditInsertionPoint object that can be queried to obtain details of the insertion point being tested, and can be used to build requests for particular payloads.
        Returns:
        A list of AuditIssue objects, or null if no issues are identified.

      • passiveAudit

        java.util.List<AuditIssue> passiveAudit​(HttpRequestResponse baseRequestResponse)
        The Scanner invokes this method for each base request / response that is passively audited. Note: Extensions should only analyze the HTTP messages provided during a passive audit, and should not make any new HTTP requests of their own.
        Parameters:
        baseRequestResponse - The base HttpRequestResponse that should be passively audited.
        Returns:
        A list of AuditIssue objects, or null if no issues are identified.

      • consolidateIssues

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