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

Group Top-Level Site Maps

Chris | Last updated: Mar 16, 2023 02:53PM UTC

I would like the ability to group top-level site-maps. For example, scanning a website's IPv4 and IPv6 address, it would be nice to group those two site maps together with a custom label. Another great use-case is when developers keep pushing new versions to different hosts. I would like to be able to group/label a sitemap with the known version number, so when I look in my site-map, it is much easier to verify 'Ok, this issue was discovered in version X, and I no longer see it in version Y.' I envision it looking similar to how tab grouping in Repeater works now. Where you can create a group, and select what site-maps you want to add. Additionally, when you select the entire group, all the issues for that group can be filtered up, vs individually ctrl-clicking on the site-maps. For example: * Version 123 ** https://172.16.22.21:443 ** https://172.16.22.21:8443 ** https://[fe80::42:e3ff:fee9:ab42]:443 * Version 189 ** https://172.16.21.23:443 ** https://172.16.12.23:8443 ** https://[fe80::42:e3ff:fee9:bd86]:443 * https://auth.corp.com * http://static.corp.com When spending a lot of time building out Repeater requests, it's often not feasible to just start a new project for the new versions. Especially when you might get a new build daily. Thanks

Michelle, PortSwigger Agent | Last updated: Mar 17, 2023 11:12AM UTC

Hi Thanks for getting in touch. This isn't something we are likely to be able to look at soon, but it is an interesting idea, so we'd like to gather a bit more information from you. Can you email support@portswigger.net so we can find out more? For example, it would be good to get a better understanding of how you envisage certain parts of this working and what kind of features would be most useful for you. - If when you selected an entire group and the issues were being filtered up, if two of the sites within the group had reported the same issue, how would you want these to be consolidated when they are filtered up? - Would you want the groups to be displayed on different tabs or would having them grouped within the same tab work for you as well?

Chris | Last updated: Mar 17, 2023 02:07PM UTC

Hi, I was thinking that the grouped 'sites' would be treated as a path under current 'sites'. And the Issue filtering would look the same. So if the grouped site map has a hierarchy like this: - Group A - https://sitea - / - /api - https://siteb - / - /api Then selecting "Group A" results in showing the issues for 'https://sitea' and 'https://siteb' just as if you Ctrl-Clicked both sites. In terms of issue consolidation, I do not see a reason to change the behavior from how BurpSuite currently behaves when multiple sites are selected. I think having the groups in the same tab would be fine. -- For my specific use-case, I like to use the same Burp Session file throughout our product review cycle which includes all phases of the vulnerability lifecycle. Initial discovery, reporting, and fix verification. Sometimes, for fix verification, we are given a new IP/Hostname with the latest build, and that is where our site-maps start to get messy and cumbersome. Thus this feature request. If I was to create a new BurpSuite Project for the new build, then I also loose all my repeater tabs with ongoing-research on the product. Likewise, I would also loose visibility to prior issues, without also having a second instance of Burp running to navigate the site-map (also ToS policy violation), or looking through the generated report. It is much easier to work with it all within a single BurpSuite instance. A possible extension to this concept might be including "snapshot" functionality. For example, I create a "Snapshot" group for a selected list of targets. Then, from that point on, no new history can be added to that specific group. Any new request would get treated as a "new" host. This would let me take all previous history, and identify it as "All issues with these requests existed for version 123. Now all new requests are for a different build version". So there could be two types of Site-Map Groups, a "Basic" group, and a "Snapshot" group. That could also make fix verification a bit easier. Example sitemap with 'Snapshot Group' - Version 123 (snapshot 2023-03-06 10:00) - https://sitea - /api + https://siteb - Version 136 (snapshot 2023-03-10 11:21) - https://sitea - /api/v1.2 + https://siteb - https://sitea - /api/v1.2 For example, half-way through the review, developers push a new CSP header which fixes an issue. Now, BurpSuite will no longer report the finding, but it still exists in the Site-Map. So now if I do validate their fix, I have to set it's state to a 'False Positive', which is not very accurate for the situation. If I was able to group the previous versions (to either a "Basic" or a "Snapshot") and their associated issues, now I can easily see the CSP issue does NOT exist in the newer scans, and I can clearly identify which version it was identified in. -- I will follow up with an email, but wanted to post this here in case others in the community also relate to my scenario. -- Chris

Michelle, PortSwigger Agent | Last updated: Mar 20, 2023 11:01AM UTC