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

Scanner misses vulnerabilitites due to improper application demarcation

Chris | Last updated: Oct 28, 2017 01:59PM UTC

Hello, Consider this scenario: Application A https://hostname/ (out of scope) Application B https://hostname/appB/ (in scope) If we choose to scan application B, then the scanner checks only application A for server level issues. So we miss the application's B vulnerabilities and at same time we touch another app that we shouldn't. Note: Target->File field is set to ^/appB/.* I noticed this bug because burp failed to detect "ASP.NET debugging enabled" on appB while an other tool did. Burp sends this: DEBUG /Default.aspx HTTP/1.1 Command: start-debug So this requests tests only application A. I have pentested so many times folder nested applications and I am wondering how many vulnerabilities I have missed so far...

PortSwigger Agent | Last updated: Oct 30, 2017 09:04AM UTC

Hi Chris, Thanks for reporting this issue. We think this is an issue with the ASP.Net Debugging scan check - it only checks the root directory, although the setting can be configured in any directory. It's not related to scope - you would have seen the same behavior if Application A was in scope. We are going to look at this and a few other tests (e.g. HSTS). One the reasons for doing this per-host and not per-directory is to avoid cluttering the results in the common case that the setting is enabled server-wide. When we've designed a better way to report such issues, we'll be able to test this per-directory. Please let us know if you need any further assistance.

Burp User | Last updated: Oct 31, 2017 04:28PM UTC

I disagree with the response from Burp that it has nothing to do with scope. If a client does not want Application A (from the example in the bug report) to be touched, then Burp should not scan it.

PortSwigger Agent | Last updated: Oct 31, 2017 04:59PM UTC

Hi Paul, That's an interesting point. We strongly respect scope boundaries at the host level. At a directory level, we mostly respect them. However, there are some checks - such as Flash crossdomain.xml - where to assess /appA/ we need to look outside that directory. These are pretty low impact checks, so there's never been a strong call to block them. Perhaps we should provide an option for "Strict scope enforcement" or similar.

Burp User | Last updated: Nov 01, 2017 04:56PM UTC

Hi Paul, Thanks... yes that would be useful, for cases where clients have strict requirements.

PortSwigger Agent | Last updated: Nov 01, 2017 05:04PM UTC