Scale Scanning Process
Purpose
This document describes the scanning procedure in Scale, and highlights the potential risks posed during a scan.
Introduction
Caution
Make sure that the private IP range 10.88.0.0/16 is not used in your environment, since this is used to communicate with a restricted container on the scanner. Having targets in this range while using the side scripts feature may cause issues while scanning them.
Scale uses the time to scan in conjunction with a set of internally defined weightings to break up the time among several stages started by the engine. In this way, assuming no issues arise in contacting the scan target or network issues, Scale provides results to the customer through the UI.
The engine always starts with these steps:
- Initialization
- Authentication (If specified)
- Crawling
Upon completion of the above stages, several actions are carried out such as:
- Pattern testing
- Component detection
- Passive XSS testing
If fuzzing has been enabled for the scan, additional actions such as time-based fuzzing, fuzzing parameters are carried out.
Factors to consider while configuring a scan:
The time required to scan that web application. Increase the time limit where it is needed. Default is 2 hours.
Determining if the risk, although minimal, posed by active scanning are acceptable.
Risks Posed During the Scan Process
This section highlights the potential risks posed to the target web application during a scan. Read through them to determine if the potential risks are acceptable when configuring the scale scan for either active or passive scanning.
A full disk drive can cause the scan engine to terminate.
Note
Contact Outpost24 for support.Pre-Fuzzing Risks
The initial stage of the scan poses little to no risk to the target website, rather the risks posted are more likely to affect the scan engine or end results. The key risks to consider during the authentication and crawling phases can be summed up as follows:
- Authentication phase: Invalid syntax in Lua scripts can cause a scan to be terminated, and invalid credentials could lead to the scan proceeding in an unauthenticated manner, which in turn skews the findings accordingly.
- Crawling phase:
The scanner clicks on links and buttons, and triggers hover events. It is possible that the scanner triggers events on a web page that do not require additional verification.
For example: Sending blank emails, opening chat sessions, delete thread options on community pages and so on.Tip
It is recommended to include them in the blacklist if they are deemed to be a risk.Another risk that may arise during Crawling stage is, network usage intensity which generally simulates multiple active users.
Tip
In rare instances, this causes a server to become unresponsive and can be avoided by setting the scan intensity to low.
Passive Scanning Risks
Due to the nature of the passive scanning process, the primary risk posed is to the scan engine itself. If the hard drive becomes full, the engine crashes and the scan is aborted.
Active Scanning Risks
Most of the risks posed during a web application scan are related to the active scanning elements. Outpost24 attempts to mitigate them through a careful manual testing of each payload or script executed by both the QA team and the SWAT Penetration testing team before being added to the Scale engine for use. In this process, known dangerous payloads, like those that would touch data in an SQL table, are not included in the SQLi payloads used by the scanner.
However, despite the thorough testing of payloads, the following risks could occur during an active scan.
When using Normal scan intensity, the engine's simulation of multiple users accessing the web application can potentially cause a resource shortage. This can result in a slow or unresponsive web application.
Tip
It is recommended to restart the scan using the low intensity scanning mode.- During XSS payload testing, if the web application is configured to save the input, it is possible that the injected XSS code may become visible to other users of the web application until the offending entry in the store is cleared.
- Sometimes, the presence of vulnerabilities cause the web application to crash rendering it unusable, until a restart is conducted.
- When testing is conducted on old or slow database servers, it is possible that the engine may cause timeout requests. In the worst-case scenario, this may lead to the database server becoming temporarily unavailable or crash, requiring a restart.
Tip
If these risks are deemed too high for the intended scan target, it is recommended to use Passive Scanning only.Additional Configuration Considerations
During normal operation, each stage returns two possible states, completed or timed-out. When a stage times out, it does not affect findings, rather it informs the user that the specific stage has run out of allocated time before completing its task based on the information provided to it.
It is possible to create multiple scanning white lists, that tell the engine where to start its scan and its crawling efforts. Alternatively, an organization can increase the total scan time. Thus, the weightings applied to each of the scan stages effectively increases the time allocated to each section, overcoming the timeouts.
Copyright
© 2024 Outpost24® All rights reserved. This document may only be redistributed unedited and unaltered. This document may be cited and referenced only if clearly crediting Outpost24® and this document as the source. Any other reproduction and redistribution in print or electronically is strictly prohibited without explicit permission.
Trademark
Outpost24® and OUTSCAN™ are trademarks of Outpost24® and its affiliated companies. All other brand names, product names or trademarks belong to their respective owners.