Burp community forum

The scanner report size is not consistant for the same web site.

Nitish | Last updated: Aug 12, 2015 10:13AM UTC

Hi we have a job (scheduled to run once a day) that invokes BURP (with carbonator extension) through cammand line. this setup is been working for quite a while. when we look at scanner reports we see that some days it is 16MB other days it is 11MB or something else. we want to know why there difference in the repoted issues (or generated report size) for the same website.

PortSwigger Agent | Last updated: Aug 12, 2015 10:18AM UTC

Differences in scan results can occur for various reasons - changes in the application code, intermittent network failures, different application data/state causing different crawl paths or issues being observed. We can probably help you more if you identify specific issues that are changing, rather than just the size of the report.

Burp User | Last updated: Aug 12, 2015 12:38PM UTC

there are no code changes, BURP is always crawling the same application everyday there is a different report generated from carbonator, its hard find any pattern. we dont push changes to our SharePoint site everyday, we were expecting BURP to find find vulnarabilities wih acceptable delta in count. but its not the case. Is this a known behavior that BURP doesnt promise a consistant result for the same application crawls. few days back i saw a thread with similar issue and they suggested turning off "Allow redirection when necessary" which did not help in my case

PortSwigger Agent | Last updated: Aug 12, 2015 01:18PM UTC

In our internal labs we have a very large quantity of test code and applications that we use to test Burp. We have overnight test runs that achieve near-100% consistency in terms of crawler coverage and vulnerability discovery. So it is not "known behavior" that Burp finds inconsistent findings. I identified some reasons why an automated scan of a target might deliver different results on different occasions. To understand the causes in your case, you might need to examine the details of the issues affected, to understand why the differences are arising. You could also try tuning the Spider and Scanner engines. In general, using fewer threads increases determinism by reducing side-effects on the server side due to concurrent access/updates.

You need to Log in to post a reply. Or register here, for free.