Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

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

Hi Paul, I've just remembered that we have this already. Look in Project options > Connections > Out-of-Scope Requests. Please let us know if you need any further assistance.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.