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

Issues are hidden if the PoC changes after an update

Jonas | Last updated: Nov 16, 2023 04:48PM UTC

Consider the following scenario: In a new Burp project, you scan a website, and it gives you the following finding: ``` #1 XSS GET /?param=testag6vc%3cscript%3ealert(1)%3c%2fscript%3eln0yc param is vulnerable to reflected xss, nothing is being escaped ``` Now you report this to your customer, and then they implement a filter that only checks for <script> within the parameter value (not an uncommon occurrence). So something like <ScRiPt> would still be possible, or other HTML elements with script execution. If you run a scan using the same Burp project again, Burp won't show this issue anymore for new audit summaries within the tasks window on your dashboard. However, if you open the audit details for that audit and go to the audit items tab, it will still show under the issues column that it recognized two issues with the severity "high", but you won't be able to find out the new PoC without going through the logger tab one by one. I think the current behavior leads to vulnerabilities being overlooked. Not everyone might be aware that Burp doesn't highlight old findings for a recheck. However, in this case, the PoC actually changed, and a pentester might be interested how to exploit it again without creating a new Burp project. Also, the example above is very easy to grasp, but what if there were a lot of other findings present? Then you wouldn't be able to easily tell which of the old vulnerabilities were actually fixed.

Dominyque, PortSwigger Agent | Last updated: Nov 17, 2023 10:12AM UTC

HI Jonas We appreciate your feedback and perspective on this. However, this is the intended functionality for issue consolidation. Burp Suite Professional identifies vulnerabilities per host and not per scan. Therefore, it is our recommendation that users create a new project file for each scan for a particular host.

Jonas | Last updated: Nov 21, 2023 10:31AM UTC

Small update in case anyone stumbles upon this thread: You can delete issues in Target -> Sitemap -> Issues, and if you do so, you will receive issues with the new PoCs. I wasn't aware of this before because it's not possible to delete issues within the dashboard itself which is rather confusing.

alexander | Last updated: Nov 22, 2023 10:56AM UTC

Hi, I am also experiencing this problem. First if you really consider this intended functionality then this should at least be consistent and logic. In my tests I did the following: 1. Scanned the application > XSS found 2. Did a bad fix of the application so that the former PoC did not work anymore but others still do 3. Did a second scan via Issue > Rightclick > Do active scan. Burp included this in the first scan. After this there was no change in the Issue Activity. However in the Audit items of this scan the last item still showed the XSS. In the issues of the scan no new issue appeared. So Audit items changes because Burp found something new but Issue acitivity does not change. Even worse Burp basically tells me: "Yeah, I found something but I do not want to tell you what I found." This is just paradoxical, even if I think of this as intended behavior. In my opinion this also is no issue consolidation. Issue consolidation would mean that if the same PoC with the same result is executed twice I would see it only once. This would be perfectly fine for me. But currently Burp is consolidating two separate issues. One issue with the first PoC before the fix and the second issue with the second PoC after the fix. This only gets weirder considering that we are talking about two scans that could be performed with months between them. I completely agree with the former post that this leads to vulnerabilities being overlooked. Frankly, I am working with Burp for years now and realized this strange behavior just yet. It is perfectly possible that some of the issues I considered fixed are in fact still exploitable. In the worst case I could be made responsible for Burp doing strange things I did not even know of. This really feels wrong when continuing working with Burp. You even provide features like "Audit again" which to me seems like specifically designed for doing a recheck after vulnerabilities got fixed or collecting PoCs in Organizer for more efficient work and then you tell me "Well Burp is not designed for that and instead is doing strange things." If you say Burp identifies vulnerabilities per host and not per scan, why do I even have the possibility to perform more than one scan for the same host? This does not make sense. Since I read in many posts about similar problems you want to gather feedback about how people are working with this feature (and it seems you are gathering this for years now without changing anything) let me tell you my intended workflow which I expect Burp to support instead Burp expecting me to adjust my workflow by doing strange things. 1. I perform a scan of the whole application I was assigned to test. 2. I check the scanner issues to filter out what really is a vulnerability and put the relevant requests in Organizer for later reference. 3. I perform additional manual tests and also put the PoCs in Organizer. 4. I report the findings using Organizer 5. The customer fixes the vulnerabilities 6. I perform a recheck. For this I repeat requests from Organizer via Repeater and also do additional automatic scans with Burp. With this workflow I use all the cool features Burp provides for maximum efficiency. Now you tell me to create a new project for the retest because Burp does strange things. For me this would mean losing all the things from my former tests that I could reuse. No sitemap, no Organizer, no Proxy history and so on. This would not only mean a huge loss in efficiency for me it also would force me to have several projects per application and with this more confusion, more storage space and so on. I really do not see any reason why I should accept all these problems because my tool for which I pay a lot of money decides for me how I have to work. So please make this feature work as I (and according to other posts a lot more users) expect immediately or tell me how you think I could work similarly efficient with the limitations this strange behvior imposes on me. If you have more questions regarding my workflow I will happily answer them.

Dominyque, PortSwigger Agent | Last updated: Nov 23, 2023 10:07AM UTC

Hi We appreciate your feedback, thank you. We have taken on board your comments and will discuss this with the appropriate teams and come back to you with a response in due course.

Dominyque, PortSwigger Agent | Last updated: Nov 24, 2023 08:41AM UTC