Burp Suite User Forum

Create new post

Active Scan insertion point types & other bugs

Chris | Last updated: Jul 11, 2020 05:26AM UTC

I found some issues with the insertion point types setting for active scans. It behaves weirdly and it seems like it has some bugs. 1. Setup: -I used Logger++ to see what is happening -I intercepted a request from the proxy and did an active scan of that request. -The request is very simple - just the header and the form data for the ajax function we are calling -I disabled all insertion point types for the scan. ------------------------------------------- PPOST /censored.com HTTP/1.1 Host: censored User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate If-Modified-Since: Sat, 1 Jan 2000 00:00:00 GMT content-type: application/x-www-form-urlencoded Content-Length: 133 Origin: http://censored DNT: 1 Connection: close Referer: http://censored Cookie: client_utc_time=plus02:00; PHPSESSID=censored; censored_cookie=en; censored_cookie=list; censored_cookie=en; censored_cookie=show; censored_cookie=show; censored_cookie=show; censored_cookie=0; censored_cookie=0; censored_cookie=203,212,272,259,306,318,302,310,296,199,313,258,315,271; censored_cookie=censored_cookie ajax=ajaxFunction&hello=somevalue&arguments[]=arg01&arguments[]=arg02&arguments[]=arg03&arguments[]=arg04&arguments[]=arg05&arguments[]=arg06 ------------------------------------------- Result: 1.1 Scanner sends post request with attached GET parameters in the url, such as: /censored.com?lYKC=1169256446 -> This is unexptected because we have disabled the setting: insertion point types: URL Parameter values 1.2 For some requests, some data is added to the header, such as X-Forwarded-For:, Referer:, C6IuESgl:, Transfer-Encoding: etc. -> This is unexptected because we have disabled the setting: insertion point types: HTTP Headers 1.3 For some requests, some random stuff is added to the body, such as f 8ilcc=x&pwbtf=x 1 Z Q -> This is unexptected because we have disabled the setting: insertion point types: Body Parameters & Entire Body 2. These tests usually takes 10 minutes or more because some requests are incomplete and cause the server to return a 408 (Request Timeout) which takes a while with default settings in apache - This means that every time one wants to test something specific, one needs to wait at least 10 additional mins before it is actually finished, which is frustrating. 3. The default setting is Max. 10 concurrent requests - however this does not seem to work correctly. From the logs in the logger it seems like only 1-3 connections are active max. this is only for these weird scans mentioned above - for other scans, this is not the case - they seem to use the full amount of conc. requests. This issue is possibly related to the request timeout mentioned in 2. 4. the form data (as per above, ajax=ajaxFunction&hello....) is controlled by the setting insertion point types: HTTP Header, which seems wrong. They are not part of the HTTP header. Took some trial & error to figure that one out. 5. The worst thing comes last, so here it goes: When scanning an item from the Audit items list again, using right click - audit again - it actually does not use the current config of the scan. It seems to use the config of when it was added. This causes a lot of unnecessary confusion and issues (at least for me). Because every time I want to rescan something with slightly different settings, I need to add that item again by going to the page, intercepting the request again and add it manualy again. Also it was very unclear why sometimes something worked and sometimes not, even though the settings were the same - well, it was because the settings were not the same when the item was added, almost blew my mind until I figured it out. Also, items can not be removed from the Audit items list - which means that there is no way to know which items uses which settings when we have duplicates (except for the position in the list - but this is not great) Hopefully my notes will help. Cheers

Chris | Last updated: Jul 11, 2020 05:28AM UTC

BTW - I had to change the text in my post above from POST /censored.com HTTP/1.1 to PPOST /censored.com HTTP/1.1 because the first version caused a 404 when trying to post.

Hannah, PortSwigger Agent | Last updated: Jul 13, 2020 07:10AM UTC

Hi Chris Thank you for your detailed notes. Do you have any extensions installed that could be performing additional scan checks?

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