Hackers target websites. Why? Because that’s where the money is. Organizations should at least know as much as the bad guys do, and that means hacking themselves before someone less desirable does it first. It also means scanning “production” websites, which carries a certain risk. Scanners can and will disrupt normal website operations unless proper precautions are taken. In theory, production systems are identical to preproduction, which would seem to alleviate the need to test them. In theory, there is no difference between theory and practice. But, in practice, there is.
Even in those websites with the most stringent change control processes, experience shows identical production and preproduction deployments are extremely rare. It is incredibly common to find hidden files and directories containing source code and logs, mismatched security configurations, infrastructure differences, and more, with each impacting the website’s true security posture. Also, for those websites with required to maintain PCI-DSS 6.6 compliance, the standard mandates scanning publicly facing websites. If scanning production websites for vulnerabilities is important to you, and it should be, then production-safety is likely equally important.
The more thorough a website vulnerability scan is, the greater the risk of disruption due to exercising potentially sensitive functionality. For example, an authenticated scanner is capable of testing more areas of an application’s attack surface than one that is unauthenticated. The same is true of a scanner custom-configured to process multi-form work flows (i.e. an online shopping cart). Furthermore, scanners testing for most of the ~26 known website vulnerability classes similarly increase the odds for causing damage. “Damage” may be as minor as flooding customer support with error email all the way up to a denial of service condition.
Clearly production-safe scanning is a legitimate concern. Below is a questionnaire about what organizations ought to know, so they can better understand the risks of production scanning and mitigate them accordingly. Please feel free to use this document to probe vendors about how their offerings ensure production-safe website scanning while achieving required levels of testing coverage and depth. As a guide, I’ve supplied the answers that apply to WhiteHat Sentinels beneath each question. Vendors may choose to do the same in the comments below, on their sites and blogs, or of course privately by customer request.
1) How is the scanner tuned, manually or dynamically, as to not exhaust website resources that could lead to a Denial-of-Service?
Scanners must share resources with website visitors. Open connections, bandwidth, memory, and disk space usage by the scanner can seriously impact operations. High-end scanners can easily generate a load equivalent to a single user, or even up to a hundred or more, unintentionally causing serious events like DoS when resources are exhausted. Each website’s infrastructure should be considered unique in load capacity. Scanning processes should be adjusted accordingly.
WhiteHat Sentinel scans consume the load of a single user. They are single threaded, exceeding no more than a user-defined number of requests per second, and generally do not download static content (i.e.. images) thereby reducing bandwidth consumption. WhiteHat Sentinel also monitors the performance of the website itself. If performance degrades for any reason, scan speed slows down gracefully. If a website looks like it is failing to respond or incapable of creating new authentication sessions, in most cases Sentinel will stop testing and wait until adequate performance returns before resuming.
2) How are multi-form application flows marked as safe-for-testing and/or removed from testing?
Depending on the website, complex application functionality can only be located by filling out multi-form work flows with valid data. Insurance applications, bill payment, password recovery, purchase processes, and more are prime examples. Some application flows are more sensitive than others, including those with a direct monetary cost when activated. Automatically scanning these areas can have consequences.
WhiteHat Sentinel does NOT automatically fill out or test HTML forms. In our experience doing so is extremely dangerous without significant preexisting knowledge about the website. Each HTML form discovered during crawling, including multi-form process flows, are custom configured by our Operations Team with valid data. The Operations team also marks individual forms as being safe-for-testing. Those HTML forms that cannot be tested safely are either tested manually or not at all.
3) Does the scanner send executable attack payloads? If so, how are such tests made safe?
Sentinel, by default, performs the majority of its tests using proprietary pseudo-code. This enables the scanner to identify vulnerabilities without the payload being interpreted by parsers within the application. This helps ensure that no errant process execution occurs that can negatively impact production software execution. Also, Sentinel does not perform any requests that are non-idempotent, perform write activity, or potentially destructive actions without explicit authorization from either a security engineer or the asset owner.
4) How are links (URLs) that point to sensitive application functionality marked safe-for-testing and/or removed from testing?
According to RFC specification, HTTP GET requests (i.e. from hyperlinks) should be treated as idempotent by applications. Meaning, no significant action other than data retrieval should be taken, even upon multiple link clicks. In practice though, many links (URLs) discovered during (authenticated) crawls can indeed delete, modify, and submit data potentially causing disruption very similarly to non-idempotent POST requests.
As part of the WhiteHat Sentinel assessment process, customers may alert us to functionality that may execute dangerous non-idempotent requests. When such areas are identifiied, they can be ruled out of the scanning process and tested manually. Also, authenticated scans are restricted to special test accounts, so any potential negative impact is restricted to those areas and do not extend to other users.