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

Burp Suite User Forum

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

SUPPORT CENTRE DISCORD

Create new post

AuditInsertionPoint type UNKNOWN used over PARAM_JSON

Birch | Last updated: Sep 03, 2024 03:35PM UTC

I am currently creating an extension that registers a burp.api.montoya.scanner.ScanCheck to perform some active and passive scan checks. While working on the active scan check, I am noticing that the AuditInsertionPoint for top level json parameters in a POST body with a content-type of application/json are represented with an AuditInsertionPointType of UNKNOWN. UNKNOWN seems to be that catch all for parsed/decoded data. Based on the list of AuditInsertionPointType's I was expecting to see AuditInsertionPointType.PARAM_JSON used in this context. Is there any documentation on when/why the various AuditInsertionPointType's are used.

Hannah, PortSwigger Agent | Last updated: Sep 04, 2024 12:44PM UTC

Hi Do you have an example request that triggers this behavior?

Birch | Last updated: Sep 04, 2024 02:16PM UTC

Below is an example request where this is occurring. When activeAudit is called for this base Request/Response no AuditInsertionPoint with a type PARAM_JSON is passed. For example the very first json property "project" is passed as AuditInsertionPoint.type() = UNKNOWN and AuditInsertionPoint.name() project. POST /REMOVED/REMOVED/track HTTP/2 Host: apim.REMOVED.com Content-Length: 475 Sec-Ch-Ua: "Chromium";v="127", "Not)A;Brand";v="99" Accept-Language: en-US Sec-Ch-Ua-Mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36 Ocp-Apim-Subscription-Key: REMOVED Content-Type: application/json Sec-Purpose: prefetch;prerender X-Api-Key: REMOVED Sec-Ch-Ua-Platform: "Linux" Accept: */* Origin: https://www.REMOVED.com Purpose: prefetch Sec-Fetch-Site: same-site Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://www.REMOVED.com/ Accept-Encoding: gzip, deflate, br Priority: u=1, i { "project": "REMOVED.com", "os": "Windows", "osVersion": "10", "browser": "Chrome", "browserVersion": "127.0.6533.100", "referrer": "", "url": "https://www.REMOVED.com/?qnid57b7b86=qnid57b7b86", "anonId": "295b5d8b-6d6d-45eb-935d-1d5b74127921", "events": [{ "name": "$mp_web_page_view", "current_page_title": "REMOVED", "current_domain": "www.REMOVED.com", "current_url_path": "/", "current_url_protocol": "https:", "current_url_search": "?qnid57b7b86=qnid57b7b86" }] }

Hannah, PortSwigger Agent | Last updated: Sep 05, 2024 03:07PM UTC

Thanks for sharing that! We'll look into this in more detail and get back to you with more information soon.

Hannah, PortSwigger Agent | Last updated: Sep 12, 2024 12:58PM UTC

Thank you for your patience. We've looked into this in some more detail, and have found the cause of this issue. The fix should be released in v2024.9 of Burp!

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