y, when session credentials are logged-out or are inactive for an extended period of time. Such scenarios are prone to denial of service via session exhaustion. For example, thoroughly testing a website requires that vulnerability scans are run in an authenticated state. And, during these scans, it is common and expected for a vulnerability scanner to become logged-out for a wide variety of reasons. So, a vulnerability scanner is required to log back in, perhaps dozens, or even hundreds of times, to continue. With each login, the website provides a new session credential in return. If this happens too often in the above scenario, it may consume all the session credential resources the website has available via its flawed design. When the session credential limit is met, no additional users can log-in — that is until the session credential garbage collection is conducted. 6) CPU Denial of Service (DoS): Many websites are designed to support an expected user flow through the application. This flow expects that users will click on certain links, in a certain order, a certain number of times, in a given amount of time. Under these assumptions, there are poorly designed websites which have hyperlinks that when clicked execute computationally expensive database queries. This, of course, is fine under normal usage. However, when an attacker targets a website, or the website receives a vulnerability scan, the traffic patterns are anything, but normal. During a vulnerability scan these computationally expensive hyperlinks may be clicked a large number of times, contrary to what was expected, and consume all of a websites available CPU resources. When the CPU is exhausted, no additional requests from anyone will be responded to. As stated above, just the simple act of crawling a website, or posting forms with valid data, can illicit this condition. 7) Verbose Logging and Run-Time Errors: Vulnerability scanning requires that a website endure a large number of abnormal requests. The requests might contain parameter names and values that weren’t expected, which could in turn raise various backend application exceptions and verbose run-time error logging. Since vulnerability scanning websites generate a huge number of requests, the disk size of the logs generated and stored could be substantial. If the verbose logging fills the available disk space, the website could be significantly harmed or at least logging might cease from that point on.
How to Avoid Harming Websites While Vulnerability Scanning