Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Having an IScannerInsertionPointProvider that only provides IScannerInsertionPoint objects to my extension's IScannerCheck

Stephen | Last updated: Sep 15, 2020 09:50AM UTC

Hi Portswigger people I have written an extension to automatically perform a variety of manipulations on URL paths, send a modified request and then check the response. For example, add various additional extensions to file names, check for particular filenames in directories, etc. I want this functionality to be accessible in a variety of ways, and Ive successfully implemented it as an Intruder payload generator as well as a scan item that works from a custom context menu. The last works by starting a thread from the menu select action that: 1. Creates a custom IScannerInsertionPoint which identifies the URL file path of my example request (e.g. the "/path/file.txt" from "GET /path/file.txt HTTP/1.1") as the thing to replace, 2. Runs the doActiveScan method of a custom IScannerCheck object that does all the appropriate replacements, sends requests and creates custom IScanIssue objects, and then 3. Adds them to the Issues list using the callbacks addScanIssue method if they don't already exist. This works well enough, but Id ideally like to do this as part of regular active scan workflow. To this end I created a IScannerInsertionPointProvider which adds my afore mentioned IScannerInsertionPoint into the active scan queue. The problem with this is that my IScannerInsertionPoint is also used by the other payloads that the active scan sends, and I haven't found any way to prevent this happening. This obviously generates a bunch more requests than are useful, and also seems to trigger the active scanners insertion point filtering behaviour, because the test active scans I have been running often don't seem to reach the point where the insertion point provides input into my IScannerCheck object. Im sure I can probably play with the scan settings to fix this, but Id prefer to configure my extension so that it doesn't make this insertion point available to other checks, because it's not useful for the majority of them. I also attempted to see if one of the existing built in insertion points would fit my needs, by running a default active scan with my IScannerCheck implementation dumping out the insertion point base values to the console. I didn't see one which appeared to operate on the URL file path. So questions: * Can I setup my IScannerInsertionPoint or IScannerInsertionPointProvider so that only my extensions IScannerCheck can access the insertion point in the active scan process? Even trying some fairly hack-ey style things I couldnt find a way to achieve this. * Is there an existing insertion point that would work for what Im trying to do? If so is there some reason this didnt appear when I tried to dump it out to the console as mentioned above? Is this due to a tuning setting in the scanner?

Hannah, PortSwigger Agent | Last updated: Sep 16, 2020 02:06PM UTC

Hi I believe by adding your insertion point to the full list of insertion points, you will be unable to prevent other scan checks being completed against that point - unless you had all "issues reported" in your scan configuration unchecked, apart from extension generated issues. Under "Insertion point types" there are options for URL path filename and URL path folders. Are these similar to the insertion point you are providing?

Stephen | Last updated: Sep 17, 2020 12:55AM UTC

Hi Hannah Yes, the URL path filename and URL path folder insertion points should be the same/similar as what Im providing, however for some reason these didn't get presented to my IScannerCheck object during testing. This prevents me from being able to tell whether they are appropriate and also made me concerned about false negatives from my extension. Is this due to the scan settings perhaps? I just used the default scan settings. A situation where the scan invisibly doesn't run unless I set the scan settings precisely is something I don't want to have to deal with, so I might just stick with the current approaches already implemented if thats the case.

Hannah, PortSwigger Agent | Last updated: Sep 18, 2020 08:57AM UTC

Have you tried isolating just those insertion points and looking in Logger++ or Flow to see how the payloads are being inserted? Physically seeing the requests and payloads may be easier to debug than outputting the base values to the console. You can also change the "Issues reported" so that you can reduce the amount of traffic generated by the scanner, making it easier to observe. Your reported issues will be under the "Extension generated issues".

Stephen | Last updated: Sep 21, 2020 01:48AM UTC

Thanks Hannah, I didn't try that, and its a good suggestion, will give it a go

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