SUPPORT

24/5 Hotline Support Service

+44 (0)20 3588 3841

Open a Support Ticket

support@netsparker.com

Do Netsparker Scans Damage Web Applications?

Netsparker is an automated web application vulnerability scanner that simulates the behavior of malicious hackers during scanning.

In order to identify vulnerabilities such as SQL Injection and Cross-site Scripting, Netsparker needs to send payloads to the target web application. Netsparker scanners are designed to run non-destructive security scans, and are obviously not malicious in intent. However, they are invasive, and their actions can affect a web application negatively.

During the scan, for example, Netsparker may inject garbage data to databases, edit some records or even delete records. Netsparker sends payloads in order to uncover issues on websites. If there is a comment area on a page, it will simulate posting comments. And if there aren't any form validations or input sanitization, those payloads will be published as regular comments. In the same way, the scanner may click a delete link or button, which could result in data loss.

You can read about various types of effects and how to minimise them in the next section.

Garbage Records and Accidental Data Loss

Netsparker crawls and finds pages on the target web application before starting the attacking phase. Crawled pages may contain input fields for user interaction.

What Happens During Scanning

How to Prevent Damage

While attacking the target web application, Netsparker's security checks help identify vulnerabilities. Each check will have different effects on the web application. For example, one type of security check may inject garbage data into the web application’s database to determine whether there is a Cross-site Scripting or SQL Injection vulnerability.

Although the parameters injected into the database are not harmful, they will create garbage comments, posts, or articles in the web application. This garbage data can be viewed by visitors, and its presence may signal to an otherwise uninformed hacker that a vulnerability exists. If a website form, for example, does not have proper validation and sanitization built in, attackers could inject OS commands or code for malicious purposes. Remember that a vulnerability exploited by Netsparker could also be exploited by a malicious visitor.

When you launch scans on test websites, during the crawling phase, Netsparker clicks all elements on the discovered page.

If you are launching a scan in a live environment, you should first ensure that a backup procedure is in place to restore critical data in case of accidental loss.

If, for example, you have a delete.php page that contains a link or button that deletes a record on the database, Netsparker would click on it during scanning. Naturally, this could damage your website. You can prevent Netsparker from testing delete.php by excluding it from the scan using our Exclude URLs with RegEx option (see Configuring the Scan).

You can also exclude HTML elements such as logout links or buttons using CSS selectors (see Causes of Logout During Scanning).

Email Floods

Many web applications have a form that redirects input entered by visitors to a specified email address.

What Happens During Scanning

How to Prevent Damage

Netsparker submits application forms or simple contact forms multiple times to check for vulnerabilities. The form generates an email each time Netsparker submits it, causing an email flood. If the email specified in the form is a group mail, many people in different departments could receive hundreds of emails during the scanning process.

This may slow down the email server until the scan is over.

It is also possible to go into an infinite loop, because of weak secure coding. This kind of an issue is treated as a DoS attack. (Please keep in mind that, while Netsparker will not launch a DoS attack or any other malicious action, negative effects may still occur due to the existing structure of the code on the website.)

One simple and easy solution is to use a temporary email address during the scanning period. You even can create email rules to block or reject emails coming from the scanner or forms.

Excluding the Send button is also another solution. This way, Netsparker will avoid clicking the Submit button.

You can also set up a CAPTCHA on each form which will help prevent email floods by determining whether or not the user is human. This is also a good way to test if the CAPTCHA element that validates input is functioning as expected.

Disallowing HTTP Methods can also be a useful way of preventing requests that may negatively affect the website during a scan.

Server Slowdown or Downtime

Netsparker sends requests to the target web server during scanning. Two things affect the number of requests sent: the size of the website and the security checks selected in the Scan Policy. In many cases, Netsparker will send thousands of requests to the target host.

What Happens During Scanning

How to Prevent Damage

Netsparker accelerates scanning time using a built-in Scan Policy Optimizer. You can also alter the number of requests per second from the default is 30 right up to 100. Setting it high may cause issues with the connection, or a DoS event.

If the target host cannot handle the amount of requests, it may run slowly or stop. The web server may stop responding, which will also affect the performance of the website. Even worse, it may not provide service to visitors. If the volume of data exceeds the network's capacity, it will also result in a bottleneck. These issues can increase the scan time to several days or weeks.

To prevent negative web server performance, try scanning the website with a small amount of requests per second. You can slow down the scan, if its performance is low. Then, when the scan is processing smoothly, you can increase the number of requests gradually.

Improving the server capacity allows the scanner to provide more accurate results.

For further information, see Scan Policy Optimizer and How Fast is Your Web Vulnerability Scanner?.

Overloading the Server With Requests

Log files can become overloaded if the web application determines that requests are unexpected data.

What Happens During Scanning

How to Prevent Damage

Scanning events and errors are logged in the web application's database or log file. Usually, these actions are recorded directly to the web server's log files too.

Netsparker can send a huge amount of traffic in a short period of time (for example, 100 requests per second). If the web application treats this as an attack, it may try to block those requests while adding them to the log files. If the necessary configurations are not added, the host server may simply run out of disk capacity.

In order to prevent Netsparker from being considered a threat, modify the headers in the Scan Policy Editor and whitelist the IPs of the machines from which requests are generated. If Netsparker is running on your own machine, use www.whatismyip.com to find your IP address, and whitelist it. If you are using Netsparker Enterprise On-Demand, whitelist the IP addresses below:

  • 54.88.149.100
  • 54.85.169.114

Netsparker allows you to choose the server location for GDPR compliance. If you want to use the EU instance, which is physically located in EU (eu.netsparker.cloud), whitelist the IP addresses below:

  • 3.121.126.156
  • 3.122.64.138
Netsparker

Dead accurate, fast & easy-to-use Web Application Security Scanner

GET A DEMO