Negative Impacts of Automated Vulnerability Scanners and How to Prevent them

Automated web application vulnerability scanners are constantly being used in order to automatically identify vulnerabilities such as Cross-Site Scripting (XSS) and SQL Injection on web applications. Although automated vulnerability scanners have become an indispensable tool for pen-testers and security consultants, they could sometimes have a negative impact on your scan target.

An automated scan damaged my web application

An automated vulnerability scanner will identify input parameters and will try to inject specific patterns to identify vulnerabilities on the target website. This is done through the scanner’s vulnerability checks. Generally, these checks are developed to be non-invasive, but there may be the case that some checks need to be invasive due to the nature of certain vulnerabilities.

For example, when checking for the two major web application security threats – SQL Injection and Cross-Site Scripting, there may be cases where garbage data is injected in the website’s database. This is especially true for Stored/Persistent XSS, where a harmless script which produces a prompt is injected into the site, such as a comment section as shown in the following screenshots. These garbage comments would be visible to anyone visiting the site, and might also cause a prompt to be shown to every user that navigates to the page.

Keep in mind that if an automated vulnerability scanner can cause such damage to your website, a malicious user would be able to do much more damage using the same vulnerabilities.

The automated vulnerability scanner crawled sensitive links

In order for an automated vulnerability scanner to be able to map out the entire directory structure of the website that you want to scan, it will analyze and crawl all the links present on each page of the website – in the same manner as having a user click on every link on your site. With each link that is crawled, new pages are discovered, and the full site structure is mapped.

This might cause problems with certain links. A good example is a ‘delete’ link that, when followed, would delete users from the database. An automated scanner cannot know the purpose of this link, and will try to crawl it too. In doing so, users might be deleted from the database. This type of problem can result in potential loss of data or broken functionality in the website.

Email flooding

If the target website being scanned by the automated vulnerability scanner is vulnerable to email flooding or mass mailing attacks, it is highly likely that a number of emails will be produced as a result of the automated scanning of the pages and forms which are vulnerable to these types of attacks. When the scanner tests each input on these pages for known vulnerabilities (and their variants), it will submit the form multiple times, resulting in the site generating an email each time the form is submitted. This is another issue that can be easily replicated by a malicious user.

The scan brought down my web server

During a scan, an automated scanner will send a number of requests to a website’s pages, forms, different variations of the same page, and so on. The number of requests that need to be sent vary depending on the size of the website and the security checks that have been selected by the user. It is common for an automated vulnerability scanner to send thousands of web requests to the web server. In order to accelerate the scanning time, automated vulnerability scanners tend to send these requests using multiple simultaneous connections.

If the web server isn’t capable of handling this amount of requests, the web server may suffer from denial of service symptoms caused by the automated scan. This may disrupt the functionality provided by the web application, and may cause the server to stop responding altogether. This will also increase the response time from the web application, resulting in an endless scan.

Excessive server logging

The requests sent by an automated vulnerability scanner would include requests that the server may not be expecting, since the scanner would be testing all inputs and pages with unexpected and sometimes random data. This could trigger errors from the web application which would be logged in the web application’s or the web server’s log files.  Since the automated scanner sends a larger number of requests in a short period of time, this will cause a huge amount of logging, potentially leading to the server hosting the web application to run out of disk space.

How to scan your site without running into these problems

Before you start thinking of spending the rest of the year manually checking your site for vulnerabilities, here are some guidelines that should be followed when performing an automated vulnerability scan on your web application.

Run scans on a staging environment

Running a web vulnerability scan on your web application should be considered part of TESTING. It is thus recommended to run such scans on a staging environment rather than a live production environment. The use of a staging environment will limit any damage done to the website during the scan to that test environment only. Therefore, users accessing your website would be unaffected by any damage caused by the scan.

Keep in mind that any vulnerabilities discovered while scanning the staging environment are probably available to malicious users on your production environment.

Restrict sensitive links from being crawled

Most automated vulnerability scanners offer ways to restrict any sensitive links from being crawled and accessed by the scanner. Make sure you configure your restricted links appropriately, so as to avoid unpleasant surprises after the scan.

If using Acunetix, this can be configured using the Login Sequence Recorder.

Use CAPTCHA in your contact forms

If you want to receive feedback directly from your website, you should ensure that you prevent the auto-submission of such forms, while keeping it simple for humans to provide you with the feedback required. One way to do this is using CAPTCHA, which helps protect forms from bots, and prevents automated scanners from flooding your mail server with unwanted emails.

You should also ensure that you check the web form for vulnerabilities. This can be done by changing the recipient’s email address in the form, so that any email flooding is done to a mailbox which is specifically used for testing.

Upgrade your web server or slow down the scan

If you, like many others, run a staging server with minimal requirements, you should upgrade the server before launching the scan.

You could also adjust and throttle the settings of the automated vulnerability scanner in order to limit the number of parallel requests and connections done during the scan, or introduce a delay between each request that is sent.

If you are forced to scan your production environment, you might also want to pause the scan during peak hours, so as not to affect users using the web application.

Conclusion

Very often, automated scanners save time when checking for vulnerabilities. Each web application is different, and thus each scan should be tailored for the web application. Acunetix provides scan automation while allowing you to easily tweak the scan settings to your web applications’ needs.