Scanning Production Environments

NOTE: Using only non-invasive techniques does not allow the scanner to identify the real potential intrusion points that attackers can use. These attackers use any and all tools and vectors available to them while trying to exploit vulnerabilities in a website. Therefore, we try to identify points of entry with the same level of effectiveness as attackers could.

What Happens During Scanning

What You Can Do

• While attacking the target web application, Invicti'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 Invicti could also be exploited by a malicious visitor.

• When you launch scans on test websites, during the crawling phase, the scanner clicks all elements on the discovered page.
• If you are launching a scan in a live production 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 to delete a record in the database, the scanner would click on it during scanning.
• Naturally, this could damage your website. You can prevent Invicti from testing delete.php by excluding it from the scan using our Exclude URLs with RegEx option (refer to Configuring the Scan Scope).
• You can also exclude HTML elements such as logout links or buttons using CSS selectors (refer to Causes of Logout During Scanning).

What Happens During Scanning

What You Can Do

• Invicti submits application forms or simple contact forms multiple times to check for vulnerabilities. The form generates an email each time Invicti 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.
• Because of weak secure coding, it is also possible to enter an infinite loop. This kind of issue is treated as a DoS attack.
• Keep in mind that, while Invicti 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 (notifications-noreply@invicti.com).
• Another solution is to exclude the Send button. This way, Invicti 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.

What Happens During Scanning

What You Can Do

• Invicti 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 number of requests, it may run slowly or stop. The web server may stop responding, which will also affect the website's performance.
• 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.
• You can run the security scan in off-peak hours by scheduling a scan.
• Utilize the Scan Policy Optimizer.

What Happens During Scanning

What You Can Do

• 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.
• Invicti 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 Invicti from being considered a threat, modify the headers in the Scan Policy Editor and allowlist the IPs of the machines from which requests are generated. 
• If Invicti is running on your own machine, use www.whatismyip.com to find your IP address, and allowlist it. If you are using Invicti Enterprise On-Demand, allowlist the IP addresses below:

• 54.88.149.100
• 54.85.169.114
• 34.237.50.127
• 3.21.226.122
• 3.19.101.63
• 52.14.107.223

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

• 3.122.90.89
• 3.122.64.138
• 18.193.27.197

• Allowlist the following IP addresses for the Canada environment:

• 35.182.99.171
• 15.223.111.146
• 52.60.130.46