Ensure vulnerability matching is checking Scope service prior to reporting findings
With regards to #357678, we need to ensure our vulnerability matching system is properly validating allowed hosts. Vulnerabilities should only be reported for hosts that validate as InScope
. As a reminder, browser based scans have three levels of scope:
- InScope - this scope level allows the scanner to request resources as well as identify vulnerabilities on hosts that match this level.
- OutOfScope - this scope level allows the scanner/browser to request resources, but should not process the responses in terms of finding new navigation paths, or finding vulnerabilities.
- ExcludedFromScope - this scope level actively denies the browser from issuing requests to these hosts.
//cc @derekferguson @sethgitlab @cam_swords
Implementation plan
-
The ScopeService
should be created using dependency injection. -
The ScopeService
should be passed into theNavigationResultMessagesMatcher
constructor. -
In NavigationResultMessagesMatcher
, each HTTP message should have the request URL check to be In Scope. If it is not, then the message should not be checked for vulnerabilities. -
The ScopeService
should be passed into theFindingService
constructor. -
The FindingService
should not attempt to check navigation results for vulnerabilities if the load request URL is notIn Scope
. -
When there is no load request, make sure NavigationResult.EndURL
is in scope, and then look at the individual HTTPMessage's URL to make sure that's in scope (if we are looking at request/responses). -
Cleanup: Move Should
methods from ScopeService to Policy, RenameShouldCheckForVulnerabilities
to includeRequest
-
For ConsoleEvent, we should be looking at the ConsoleEvent.URL
.
Edited by Cameron Swords