This article applies to:
Question:
- What is the Attack Boundary?
- How does App Scanner control what is injected?
Reply:
The Attack Boundary limits where App Scanner will send injections when running SmartAttacks during an assessment. This is separate from the white/black/additional hosts list on the spider, which controls where the spider is allowed to traverse.
The Attack Boundary has the settings shown and explained below:
Server of Starting URL
By default, App Scanner limits attacks to the server (exact site name) of the starting URL. If your target application is located at app1.example.com, App Scanner only sends injections to app1.example.com. If a form submission or other resource calls app2.example.com, App Scanner does not inject the form submission to app2.example.com. The spider may still submit the form with default values or attempt to traverse the page. This spider behavior is controlled in the spider settings.
Domain of Starting URL
When you select 'Domain of Starting URL', App Scanner will send injections to any resource which is included in the base domain of the starting URL. If your target application is located at app1.example.com, App Scanner will send injections to any resource seen which has a URL site name ending in example.com. This means if App Scanner sees a form submission to app2.example.com, the form submission will be injected.
Do not limit attacks
This setting is not recommended for most situations. If your target application calls outside resources such as the Google Maps API and the Attack Boundary is set to 'Do not limit attacks', App Scanner will attempt to inject requests to the outside resource. This can result in your scan attacking third party resources outside of your control.
Limit attacks to specified host(s)
This option allows you to specify which hosts will be injected. You can add a comma separated list like the following:
app1.example.com,app2.example.com
The above list tells App Scanner to inject requests to app1.example.com or app2.example.com, but not to inject any other resources. This setting allows you to include multiple hosts for injection while still restricting exactly what is injected on each assessment.
As of App Scanner 8.6, it is possible to set a blank list with no hosts specified. If this option is selected and the host list is blank, the application defaults to the 'Domain of Starting URL' for the Attack Boundary.
Attack Boundary in the Logs
You can see what the attack boundary is currently set to by looking in the logs for the following line:
hsPE.hsTestEngine.getHostBoundaryChecker;
Below is an example of the attack boundary at work. The assessment is configured to scan app1.example.com. Somewhere in the application is a link to app2.example.com/login.php. The hsTestEngine observs a request to app2.example.com/login.php. We evaluate the URL based on the Attack Boundary. Since the Attack Boundary is set to <server-of-starting-URL>, we are not allowed to inject app2.example.com. A message will be sent to the UI showing we did not inject the forbidden host. We also see a message showing the URL being 'disallowed due to: Job'.
hsPE.hsTestEngine.observe; onRequest: URL = http://app2.example.com/login.php (top-level)
AppLog; Host Boundary Checker [Info] Host Boundary Check for "app2.example.com" disallowed due to: Job
BackendComm; logMessage2: JobLog; Level: 5, Sender: Host Boundary Checker
BackendComm;-JobLog;- Message: AppLog [Info] Host Boundary Check for "app2.example.com" disallowed due to: Job
BackendComm;-JobLog;- Details:
Common; sendApplicationLogMessagetoUI: Host Boundary Checker: Info: Host Boundary Check for "app2.example.com" disallowed due to: Job
hsPE; Ignoring disallowed host "app2.example.com"
BackendComm; logMessage2: JobLog; Level: 4, Sender: hspe
BackendComm;-JobLog;- Message: Ignoring disallowed host "app2.example.com"
BackendComm;-JobLog;- Details:
hsPE.hsTestEngine.callback; ** ignoring request to forbidden host from traversal: URL = "http://app2.example.com/login.php"
