Burp Suite User Forum

Create new post

Passive Scanning of Active Scan Results

August | Last updated: Jan 18, 2017 07:56PM UTC

In Extensions, do passive scan checks (implementing IScannerCheck.doPassiveScan) automatically get applied to all responses of active scans as well? Or is passive scanning only done for the initial request/response and ignored thereafter? If you want to run the same checks on active scan responses do you need to explicitly implement IScannerCheck.doActiveScan?

PortSwigger Agent | Last updated: Jan 19, 2017 09:15AM UTC

When the user performs an active scan of an item, all active and passive scan checks are performed. So if your extension has registered a passive scan check, it will automatically be run on items that the user actively scans.

Burp User | Last updated: Jan 19, 2017 09:39PM UTC

That does not appear to be the case. I've created a very simple passive scanner extension that simply increments a counter each time doPassiveScan and doActiveScan is called and then prints the count to the console (https://github.com/augustd/burp-suite-passive-scan-test/blob/master/src/main/java/burp/BurpExtender.java). When I scan a URL that has 5 insertion points I can see that doPassiveScan is called once, and doActiveScan is called 5 times: Doing passive scan: https://some.domain.com/sandbox PASSIVE: count: 1 https://some.domain.com/sandbox Doing active scan: https://some.domain.com/sandbox ACTIVE: count: 1 https://some.domain.com/sandbox Doing active scan: https://some.domain.com/sandbox ACTIVE: count: 2 https://some.domain.com/sandbox Doing active scan: https://some.domain.com/sandbox ACTIVE: count: 3 https://some.domain.com/sandbox Doing active scan: https://some.domain.com/sandbox ACTIVE: count: 4 https://some.domain.com/sandbox Doing active scan: https://some.domain.com/sandbox ACTIVE: count: 5 https://some.domain.com/sandbox During the course of the active scan, Burp actually made 225 requests, but doPassiveScan was only called once. What would I need to do to make my scanner checks run on every single response?

PortSwigger Agent | Last updated: Jan 20, 2017 09:07AM UTC

Sorry, I misunderstood your question. Passive scan checks run automatically when something is sent for active scanning, but they run only on the base request/response, not every request/response that occurs during scanning. You can achieve what you want by registering an IHttpListener, monitoring for responses for the Scanner, and doing whatever analysis of them you wish. You can add scan issues that result from this analysis using IBurpExtenderCallbacks.addScanIssue().

Burp User | Last updated: Jan 20, 2017 07:02PM UTC

Under what conditions is doPassiveScan run automatically? From my testing it appears to be: - First request of an active scan - Proxy requests - Any time 'Do a passive scan' is selected from the context menu doPassiveScan is NOT getting called: - On every active scan request - On Repeater requests - On Intruder requests Is this correct?

Burp User | Last updated: Jan 20, 2017 07:11PM UTC

If I implement IHttpListener to scan all responses, and then add issues with IBurpExtenderCallbacks.addScanIssue(), how is consolidation of duplicates done? Do I add custom code to get all existing scan issues for a particular URL (with callbacks.getScanIssues) and compare them myself? Or is it better to use callbacks.doPassiveScan instead? Will that take advantage of Burp's native issue comparison? Will that cause _all_ passive scan checks to be run, or just the ones from my extension?

PortSwigger Agent | Last updated: Jan 23, 2017 09:54AM UTC

Your description of the situations where passive scanning is performed is correct. You're also right that issue consolidation isn't done for issues added via IBurpExtenderCallbacks.addScanIssue(). It is only done for issues generated for a specific insertion point by implementing a custom scan check. The solution of calling doPassiveScan() for each request/response that occurs during active scanning might be the best option. It will cause all passive scan checks to be run, not just extension-provided ones.

Burp User | Last updated: Jan 23, 2017 08:29PM UTC

I'd rather not force all passive scan checks to be run if I don't have to. I can't be sure what other passive scan extensions a user might have loaded/don't want to cause that extra overhead just to run my own extension's checks. Would you consider exposing a method in the callbacks to do add-if-unique?

PortSwigger Agent | Last updated: Jan 24, 2017 03:55PM UTC

The problem is how to decide whether an issue is unique. The existing issue consolidation logic is implemented by custom scan checks. When two issues are generated at the same location by the same custom scan check, Burp asks the check whether it should consolidate them. For issues added asynchronously using IBurpExtenderCallbacks.addScanIssue(), there isn't anything corresponding that can do the consolidation work. So for what you're trying to achieve it might just be that you need to track within your extension whether the issue is new and should be reported. Alternatively, you could use the API to retrieve the existing issues for a given URL, identify your own extension's issues amongst them, and decide whether your new issues should be reported before you do so.

Burp User | Last updated: Jan 24, 2017 06:54PM UTC

That's basically what I have done here: https://github.com/augustd/burp-suite-error-message-checks/pull/8/files#diff-7b46e29e6a2462815fb1ed201092482cR114 I'm pulling all issues from the same URL prefix, then constructing an overridden IScanIssue which implements Comparable, hashCode() and equals() so I can put them into a HashSet. Then I check whether the HashSet already contains() the newly constructed ScanIssue. If not, I add it to Burp. One thing I've noticed is that when you use callbacks.addScanIssue(newIssue) that does not actually show the issue in the Scan Queue tab -The issue only appears in the Target tab. A better approach might be to expose a method that allows developers to call doPassiveScan on their own extension only.

PortSwigger Agent | Last updated: Jan 25, 2017 09:11AM UTC

Yes, using callbacks.addScanIssue(newIssue) won't add the issue to anything in the scan queue since the issue isn't associated with any particular scan item. We'll think about whether it would be feasible to provide the API you suggest.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.