Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Issue and question when implementing a ScannerInsertionPointProvider

blunden | Last updated: Jul 02, 2016 03:51PM UTC

Hi, Earlier this week I implemented a ScannerInsertionPointProvider to allow the active scanner to scan the custom type of multi-value parameters used by an application I was testing. Basically some parameters contained multiple values separated by one of a few separator characters (usually a special character like ~, _, ! etc.) where each value was then handled separately by the application. This meant that the application could be vulnerable to injection vulnerabilites in one sub-value of the multi-parameter but not others. Overall the extension worked well but I ran into a few issues. 1. Burp doesn't properly save all identified issues, ie. some issues show up when looking at the scanner issues in the scan queue but not under Target and as a result they don't end up getting saved in the state file. Am I correct in assuming this is because Burp removes what it considers duplicate issues, ie. issues of the same type inside the same parameter? If so, can I exclude issues found in my insertion points from that somehow? 2. When implementing the getPayloadOffsets(byte[] payload) method I base the calculations on the return value of getValueStart() from the parameter object obtained from the original baseRequest. It turns out that this doesn't work properly because the updateParameter method changes the order of the body parameters. Can I safely assume that buildRequest method of the InsertionPoint object will always be called before getPayloadOffsets? If so, I suppose obtaining the new parameter offset for the parameter from there should work.

PortSwigger Agent | Last updated: Jul 04, 2016 09:22AM UTC

We created a quick extension to test this scenario, and we didn't run into any problems. 1. Burp does do consolidation of issues based on insertion points, but it should treat your insertion points as distinct. Burp doesn't actually know that you are manipulating values within a given parameter, so won't try to do anything clever based on that. Make sure you give each insertion point that you create a distinct name - for example, by appending the index number of the sub-parameter that you are working on. 2. This will depend on your implementation, in terms of how you are building new requests. It's probably safe enough to make assumptions about the order of method invocation if that works for you since we're unlikely to change that behavior any time soon.

Burp User | Last updated: Jul 07, 2016 01:18AM UTC