2

Almost all of my XSS false positives come from Burp sending raw byte array payloads to the server and getting the same response injected into DOM or whatever. But in real world browsers automatically URL encode requests (RFC standard), and this is something Burp can't yet handle. Or at least I couldn't find it.

Do you have something for this? I'm talking about the Scanner explicitly.

I would've made an extension that implements IScannerInsertionPointProvider correctly, but as far as I know there's no way to apply it only for XSS payloads. There are some other vectors where non-urlencoded version is the one I want to use.

  • 2
    Just curious, why do you consider these as false positives? You don't want your server to rely on client-side (browser) protections like always URL encoding requests correctly. – Jedi Aug 4 '17 at 15:18
  • The client wants us to only report real risks. As far as I know, all major browsers url encode params, and of course you can't simply find someone with Netscape 3, send an URL to him and wow it executed. We were getting a lot of these XSSes lately, like hundreds of entries for a few applications, and it's really overwhelming to go and check them one by one - if I could just tell burp to act like a real browser... – Rápli András Aug 5 '17 at 10:56
  • Just because you cannot replicate it using a browser, doesn't mean it's not real. The Burp report should give you more details. Remember, an adversary is probably not going to be using a browser. – Jedi Aug 5 '17 at 13:34
2

It sounds like these are genuine findings.

Be aware that Internet Explorer does not encode less-than signs in URLs. Have a go at reproducing the finding using IE. If you are not able to, that indicates something else is going on.

If you need further assistance, please email support@portswigger.net and include screenshots of a false positive.

  • Soliciting email replies is not accepted here. You may link to your web site or email address from your profile if you like, but it does not belong in this answer. – tripleee Aug 7 '17 at 8:23
  • If you are really from Burp support team (not the commercial team for instance...), your answer (more a comment than an answer btw) surprises me. Maybe you've read the OP question too fast, as the OP seems to complain that Burp doesn't escape special chars as genuine browsers do, however an attacker will precisely use raw, unescaped chars in order to exploit a server vulnerabilities. Attacker do not care of RFCs, on the contrary they will happily violate them as long as it allows to break into the target. Burp is just acting as expected. – WhiteWinterWolf Aug 7 '17 at 8:31
  • @tripleee - Fair enough. We find that users are often unwilling to share useful diagnostic information like screenshots in public forums, so moving the conversation to email is useful. – PortSwigger Aug 7 '17 at 8:53
  • 2
    @WhiteWinterWolf - This is the Burp support team; my personal account on here is paj28. I'm not quite sure why our answer surprises you. XSS vulnerabilities typically take place in a victim's browser. If all common browsers did encode in this scenario then this may well be a false positive. Pointing out the common browser that doesn't encode is indeed the answer to this question. – PortSwigger Aug 7 '17 at 8:57
  • @PortSwigger: Ok, thanks for your comment, now I follow the reasoning behind your answer :) ! – WhiteWinterWolf Aug 7 '17 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.