Extensions can implement this interface and then call IBurpExtenderCallbacks.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 ide
| 19 | * Scanner issues that are identified. |
| 20 | */ |
| 21 | public interface IScannerCheck |
| 22 | { |
| 23 | |
| 24 | /** |
| 25 | * The Scanner invokes this method for each base request / response that is |
| 26 | * passively scanned. <b>Note:</b> Extensions should only analyze the |
| 27 | * HTTP messages provided during passive scanning, and should not make any |
| 28 | * new HTTP requests of their own. |
| 29 | * |
| 30 | * @param baseRequestResponse The base HTTP request / response that should |
| 31 | * be passively scanned. |
| 32 | * @return A list of <code>IScanIssue</code> objects, or <code>null</code> |
| 33 | * if no issues are identified. |
| 34 | */ |
| 35 | List<IScanIssue> doPassiveScan(IHttpRequestResponse baseRequestResponse); |
| 36 | |
| 37 | /** |
| 38 | * The Scanner invokes this method for each insertion point that is actively |
| 39 | * scanned. Extensions may issue HTTP requests as required to carry out |
| 40 | * active scanning, and should use the |
| 41 | * <code>IScannerInsertionPoint</code> object provided to build scan |
| 42 | * requests for particular payloads. |
| 43 | * <b>Note:</b> |
| 44 | * Scan checks should submit raw non-encoded payloads to insertion points, |
| 45 | * and the insertion point has responsibility for performing any data |
| 46 | * encoding that is necessary given the nature and location of the insertion |
| 47 | * point. |
| 48 | * |
| 49 | * @param baseRequestResponse The base HTTP request / response that should |
| 50 | * be actively scanned. |
| 51 | * @param insertionPoint An <code>IScannerInsertionPoint</code> object that |
| 52 | * can be queried to obtain details of the insertion point being tested, and |
| 53 | * can be used to build scan requests for particular payloads. |
| 54 | * @return A list of <code>IScanIssue</code> objects, or <code>null</code> |
| 55 | * if no issues are identified. |
| 56 | */ |
| 57 | List<IScanIssue> doActiveScan( |
| 58 | IHttpRequestResponse baseRequestResponse, |
| 59 | IScannerInsertionPoint insertionPoint); |
| 60 | |
| 61 | /** |
| 62 | * The Scanner invokes this method when the custom Scanner check has |
| 63 | * reported multiple issues for the same URL path. This can arise either |
| 64 | * because there are multiple distinct vulnerabilities, or because the same |
| 65 | * (or a similar) request has been scanned more than once. The custom check |
| 66 | * should determine whether the issues are duplicates. In most cases, where |
| 67 | * a check uses distinct issue names or descriptions for distinct issues, |
| 68 | * the consolidation process will simply be a matter of comparing these |
| 69 | * features for the two issues. |
| 70 | * |
| 71 | * @param existingIssue An issue that was previously reported by this |
| 72 | * Scanner check. |
| 73 | * @param newIssue An issue at the same URL path that has been newly |
| 74 | * reported by this Scanner check. |
| 75 | * @return An indication of which issue(s) should be reported in the main |
| 76 | * Scanner results. The method should return <code>-1</code> to report the |
| 77 | * existing issue only, <code>0</code> to report both issues, and |
| 78 | * <code>1</code> to report the new issue only. |
nothing calls this directly
no outgoing calls
no test coverage detected