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

Issue type vs Issue name uniqueness in scanner XML output

Daniel | Last updated: Aug 19, 2016 03:20PM UTC

Hi team, I'm working on the Burp parser for Dradis (http://dradisframework.org) and one of our users has reported an issue with the way two different findings are reported under the same Issue type number. It seems that both "Form does not contain an anti-CSRF token" and "Request vulnerable to Cross-site Request Forgery" are currently being reported under the same type number (134217728). 134217728 - Form does not contain an anti-CSRF token - 6992870079567348736 - Request vulnerable to Cross-site Request Forgery - 53124601307604992 Unfortunately in Dradis we use the issue type to uniquely identify an issue across Burp XML uploads, to avoid creating duplicate findings into the project. As a result, if the Burp XML has two <issue> blocks with a <type>134217728</type> but different <name> values, we end up with a single Issue (the evidence for each instance is still captured). I suspect this is caused by Burp Scanner detecting the same problem two times: 1) when it loads the page, the form is missing a CSRF token; 2) when the auditor submits the form, the request is missing the CSRF token; Hence the decision to report it under a single type ID. I've checked and the <issueBackground> and <remediationBackground> are the same, only the <issueDetail> changes, which makes me think this is just intentional (albeit maybe confusing to report the same problem twice - one when inspecting the response and one when inspecting the following request). Usually different <name> values are associated with different <type> values. Was this an oversight? Are you planning to start doing this in the future or for other issue types? If so we would need to update our parser. Any light you could shed on this will be really appreciated. Thanks! Daniel

Liam, PortSwigger Agent | Last updated: Aug 19, 2016 03:32PM UTC

Hi Daniel Thanks for your message. We only have one CSRF issue. Where has this issue listing come from? - Form does not contain an anti-CSRF token - 6992870079567348736 It has not been created by Burp Suite - https://portswigger.net/KnowledgeBase/Issues/

Burp User | Last updated: Dec 27, 2017 04:34PM UTC