Incorrect aggregation of Burp extension generated findings

[artoj]

Bug description

Using DefectDojo version 2.10.0 deployed with Docker Compose. When importing Burp Pro XML scan results to DefectDojo, the Burp extension generated findings are merged in to a single finding.

Extension generated findings can be different in type and may have no relation to other extension generated findings

The relevant code snippet is: https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/tools/burp/parser.py#L37 item.vuln_id_from_tool is a value that is same for all Burp extension findings, see: https://portswigger.net/kb/issues/08000000_extension-generated-issue

Steps to reproduce
Steps to reproduce the behavior:

1. In Burp Pro, export extension generated findings to XML
2. Import the generated XML to DefectDojo.
3. Observe that the findings have been merged in to a single finding even though the findings may be of different type.

Expected behavior
Burp extension generated findings (of different type) are not aggregated.

Deployment method (select with an X)

• Docker Compose
• Kubernetes
• GoDojo

Environment information

• DefectDojo version: 2.10

Source code
https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/tools/burp/parser.py#L37

[remote-tty1]

I had the same issue and in my lab env I worked around it by changing line 37 into dupe_key = f"{item.title}_{item.vuln_id_from_tool}" to aggregate them only if there is also a match in the title but idk if there is a cleaner and safer approach

[damiencarol]

@remote-tty1 a patch is in progress to remove this internal aggregate non-sense.

[fopina]

But does it make sense to even aggregate on type or title alone, in your opinion, guys?

I've recently changed it in my fork to also split on endpoint (and to properly include full endpoint, rather than just host)

I've asked that in #11398

(And just saw it's open for 3y now yes 🤦 )