In this day and age when data is the most valuable asset for most businesses, it’s quite obvious why there are now more occurrences of data breaches and cyber-attacks all over the world.
With that being said, performing vulnerability scanning is one of the most cost-effective and easiest ways for businesses to identify any security vulnerabilities in their network, system, and integrated applications.
However, if the vulnerability scanning is not planned and executed properly, it can actually harm your website, and this is especially true if you are relying on free vulnerability scanners from untrustworthy vendors.
First thing first, we can generally divide vulnerability scanners into two different categories: invasive and non-invasive.
A non-invasive vulnerability scanner is typically 100% safe and won’t harm your website, but it will only scan the “surface” of your website, network, and/or application with basic tests. An invasive scan, on the other hand, is more comprehensive and is more effective in scanning your system’s vulnerabilities. However, invasive vulnerability scanning essentially works by simulating a real attack vector, which may expose your system to real attackers and harm your website.
Sometimes, the harm is negligible, but other times, the impact can be severe and can stop your website from operating.
For example, poorly designed invasive vulnerability scanning may submit poorly-made meta-character strings into various areas of your website (i.e. URLs), which can harm the website.
However, there are cases when invasive scanning is absolutely necessary, for example when checking for vulnerabilities for persistent attacks.
Below, we will discuss the best ways to avoid harming your website when running an invasive vulnerability scanner.
The general principle is to ensure a backup procedure is in place before performing invasive vulnerability scanning on your site.
We’d recommend following the classic 3-2-1 backup rule:
This way, even if the vulnerability scanning ends up harming your website even after you’ve performed the other best practices, you can ensure minimal disruption to your website and business operations and promote a speedy recovery.
You can use various botnet attack prevention and detection security techniques that are capable of autopilot scanning with minimal interruptions to your processes which will minimize the need for invasive vulnerability scanning.
The general rule of thumb is, only perform vulnerability scanning when it’s absolutely necessary.
Before running an invasive vulnerability scanner, you should manually identify high-risk and sensitive areas manually as much as possible. Then, rule them out of the automatic vulnerability scanners.
You should test these high-risk elements manually to complement the vulnerability scanning if possible. Also, if you are performing authenticated vulnerability scanning, restrict it to special test accounts to mitigate potentially harmful impacts.
Whenever possible, make sure the vulnerability scanner’s injection payloads are non-invasive and 100% safe before running them. For example, make sure the test command like ping is designed to end otherwise they’ll loop forever.
When using SQL injection payloads, make sure they don’t contain UPDATE and DROP statements, or else the payload may accidentally delete or modify your website’s data.
The basic rule is that your vulnerability scans should always be idempotent and they should not perform write activity or potentially modifying actions without authorization.
Your vulnerability scanner solution should include an option to restrict access to any sensitive links. For example, hyperlink URLS that can initiate non-idempotent functions are considered sensitive, since when a vulnerability scanner crawls these links, it can significantly affect the whole website’s performance.
Make sure to properly configure your vulnerability scanner to exclude these sensitive links from the automated scanner. It’s best to keep a list of sensitive links for this purpose and monitor your whole system for the addition of new sensitive hyperlinks from time to time.
If your website is particularly sensitive but a vulnerability scan is unavoidable, then a viable option is to run the vulnerability scanning on a staging environment rather than on your live website. Doing so will limit the potential harm done to the actual website during the scan only to the staging environment. Thus, your site visitors can still access your site while you can fix the issue behind the screen.
Keep in mind, however, that users of your staging environment can potentially access and exploit any vulnerabilities found during the vulnerability scanning. Also, your staging environment might not be 100% identical to your production environment, and the vulnerabilities identified might not be identical.
The first series of vulnerability scans should be performed as a single-threaded user.
By doing so, if the website slows down during the scan, or fails to respond, the scanner will also slow down. The scanner will not make the next HTTP request until a response to the previous request was received, and if the website failed to respond within a given time limit, the scanner will stop testing and alert the user.
Only when the website’s performance returns to normal will the scanner resume the scanning process. Otherwise, the scanner can send multiple requests to the server, causing an effect similar to a DDoS attack, potentially crashing the website down.
Proper planning and preparation of the vulnerability scanning process are very important.
Invasive vulnerability scanning essentially puts your website to a test to endure a large number of abnormal requests, including unexpected/abnormal values and strings. Also, the number of requests generated can be huge, and if your web server can’t handle the load, it can potentially crash your website.
By following the seven tips we’ve shared above, you can effectively avoid such issues and prevent the vulnerability scan from harming your website.
Also Read: SEO: How To Land Your Website At The Top Of Google & Co