Problems with Burp Finding Data

Malformed data complicates report processing

Just making a note of this…maybe report it to PortSwigger later or maybe they will find this.

There are some issues with data coming out of Burp that make processing complicated and cause me to spend hours making tweaks to data that should just work. Here are a few examples:

The same finding type ID is used for different types of findings. Perhaps I misunderstand the purpose of this value but there should be a value in the data set which uniquely identifies a finding with a particular name and description. The serial number appears to be each individual finding, so I presumed the finding type ID was supposed to be this unique finding type value. However, when looking into the details I can’t use the value to group items because it is used for different types of findings:

Finding Type 134217728 has multiple names. The following findings all fall under this same “finding type” making it difficult to process the data or identify unique items.

JS Miner Dependency Confusion

Vulnerable version of the library ‘jquery’ found

User-Agent HTTP header

[JS Miner] Secrets / Credentials

Collaborator Pingback (HTTP): Referer

NoSQL/SSJI Injection Detected

NoSQL Injection Detected

Singlequote plus slash

Interpolation fuzz

Interpolation — curly

Interpolation — dollar

Interpolation — percent

Some findings have HTML in the description. For example: Interpolation Percent. Would prefer not to have the risks associated with injected code in findings.

Some of the types with multiple findings change the description and add a line at the end: “This issue was found in multiple locations under the reported path.” Because the description is not consistent, if you’re trying to group on description you’ll get multiple of the same issue.

Some findings do not have a description and appear to be putting the description in the detail field. This causes me to have to check to see if a description exists, otherwise make the detail the description, otherwise display the detail for a specific target. This processing extra processing could be eliminated if the detail, which appears to actually be a description and not specific to a target, was in the right location in the finding.

Separate URLs from their descriptions. I don’t want to just import every URL from every finding and assume it’s OK and pass that through to a customer report. I would also like to automatically visit those URLs.

Some of the details for a finding have varying line breaks and spacing. Remove the html tags and make these things consistent.

Some findings have no description or no remediation. These values seem like they should be required.

The remediation for some findings is “panic”. That is not really helpful.

Some of the descriptions have “Resources” embedded in them when there’s a separate field for resources. Move those to the proper location.

Do not put extension names in the finding name or the description. the finding name is the finding name, not the tool that produced it. For example, [JS MINER] and [SSL SCANNER]. Also, do not put the extension name in the description. I have to do a lot of one-off parsing to work around that issue.

Put the extension in separate field in the XML output. Let the person creating a report do with it what they wish.

Resources should be a list of resources for a finding not a blob of text. The report writer should be able to iterate the name and URL of a list of resources.

Move targets into a list associated with each finding. This will enable much more efficient processing by reducing the need to parse common values over and over again such as the name and description of the finding. It will also help enforce data integrity because each finding type should have one name and one description which is not currently the case. Of course, this will beak existing reporting engines, so for backwards compatibility have a V1 and V2 option.

Add the option to convert one finding to another type. For example, the SQL injection findings contain SO many false positives. However, sometimes they produce interesting detailed error messages. I would like to be able to move some of the SQL Injection findings over to the detailed error messages category. In addition, sometimes detailed error messages show vulnerable libraries. I would like to be able to move those to a vulnerability finding type instead and list out the vulnerable libraries and assign a risk.

I would love to be able to search by a finding category. For example, if I created a report and list each finding type ID and associated targets with their details, then let me enter the finding type ID in the search bar and filter on that particular category of findings in the UI.

There is a unique number in the UI for burp findings which does not show up in the output report file. Need a unique number in the file and the output for each finding that matches.

I have a reasonable work around to all of this but a little data clean up would make my reports run much faster. :-)

P.S. Burp is awesome.

Teri Radichel

If you liked this story please clap and follow:

Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research