What tests are performed by Website Scanner?

The complete list of tests performed by the website vulnerability scanner with details on how each test works.
Written by Stefan Bratescu
Updated 8 months ago

The tests can be configured by selecting the Custom Scan Option.

These tests are recommended for all applications. You can skip any of these, depending on the target application typology. The scan duration will vary depending on the number and the complexity of the tests you select to perform.

1. Initial tests

1.1 Fingerprint website

Fingerprinting tries to find information about the used output and it will result in a list of the detected used technologies, tools, third-party software, and their version. This information can serve as a starting point for an attacker, by giving them some directions to further investigate.

1.2 Server software vulnerabilities

The Server software vulnerabilities test checks if the server software is affected by known vulnerabilities. Will output CVEs and a description of the vulnerabilities.

1.3 Robots.TXT

The Robots.txt test checks for the existence of the robots.txt file and extracts any URLs that are present and in-scope for further analysis.

1.4 JavaScript libraries

The JavaScript Libraries test checks if the application uses any outdated JavaScript libraries, which are affected by known vulnerabilities. The output will be a list of such detected vulnerabilities.

1.5 SSL/TLS certificates

The SSL/TLS Certificates test checks if the SSL/TLS Certificate the server presents is trusted by the browser. The most common causes for this error are that the certificate is self-signed, the issuer is untrusted, or it is not valid for the domain of the application.

1.6 HTTP Debug Methods

This test checks whether HTTP TRACK / TRACE methods are enabled on a webserver.

1.7 Client access policies

Client Access policies are a set of rules in XML files used by Adobe Flash and Microsoft Silverlight clients in the browser. These files specify which parts of the server should be accessible, and to which external domains. 

We define a vulnerability as allowing any domain to request data from the server, which is identified by a wildcard (a * operator) in certain XML tags in the policy files. 

This is not necessarily a problem if the website is supposed to be public, but might be a vulnerability if the tested website is supposed to have restricted access.

1.8 Resource discovery

Resource Discovery researches common files and directories that represent a possible liability if exposed. However, be aware that this will increase the overall scan duration. By default, this initial test is unselected because it adds a significant amount of time to the scanning process. However, you can select it when ready to let the scan run, without a time constraint.

2. Active checks

Check for vulnerable parameters that might give access to sensitive information. The engine crawls the target application, then it sends various inputs into the parameters of the pages and looks for specific web vulnerabilities such as SQL Injection, Cross-Site Scripting, Local File Inclusion, OS Command Injection.

2.1 Cross-Site Scripting - XSS

The XSS test will try to detect if the application is vulnerable to Cross-Site Scripting by injecting XSS payloads and analyzing the response.

2.2 SQL Injections

The SQL Injections test checks for SQL injection vulnerabilities found in web applications by crawling, injecting SQL payloads in parameters, and analyzing the responses of the web application.

2.3 Local file inclusion

Local file inclusion occurs when the web application shows arbitrary files on the current server in response to an input in a parameter.

2.4 OS command injection

Command injection is an attack in which the goal is the execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user-supplied data (forms, cookies, HTTP headers, etc.) as Operating System commands.

2.5 Server Side Request Forgery

Server-Side Request Forgery (SSRF) is a vulnerability that allows a user to force the backend server to initiate HTTP requests to arbitrary URLs specified in the input parameters.

2.6 Open Redirect

The backend server incorporates user input into URLs used for redirection. An attacker can use this to redirect users to arbitrary domains.

2.7 PHP Code Injection

PHP Code Injection happens when user input is incorporated into a call to a PHP function that interprets and executes code, like eval(). This allows a malicious user to execute arbitrary PHP code on the server.

2.8 Server-Side JavaScript Code Injection

JavaScript Code Injection happens when user input is incorporated into a call to a nodeJS function that interprets and executes code, like eval(), setTimeout(), vm.runInContext(). This allows a malicious user to execute arbitrary JavaScript code on the server.

3. Passive checks

Passive checks analyze the HTTP responses from the server to find weaknesses in your system.

3.1 Security headers

HTTP security headers are a fundamental part of website security. They protect against XSS, code injection, clickjacking, etc. This tests checks for the common security headers.

3.2 Cookies security

Checks the use of :

  • the HttpOnly attribute to prevent access to cookie values via JavaScript.
  • the Secure attribute to prevent the sending of Cookies over HTTP
  • the Domain attribute indicates which hosts the cookie should be sent to; be careful with this, as including a hostname will also send cookies to all of its subdomains. For example, domain = google.com also sends the cookie to maps.google.com, mail.google.com, etc.

3.3 Directory listing

Directory listings might constitute a vulnerability if it gives access to the server configuration or other sensitive files.

3.4 Secure communication

Secure communication tests if the communication is done over HTTPS instead of HTTP, which is not encrypted.

3.5 Weak password submission method

If the communication is done over HTTP, we check if the credentials are submitted using transparent methods like HTTP Basic or Digest Authentication.

3.6 Commented code / Error codes

Tests if there are suspicious code comments or if the application responds with stack traces or too verbose error messages on certain inputs.

3.7 Clear text submission of credentials

Tests if the user credentials are sent over HTTP as opposed to HTTPS.

3.8 Verify domain sources

Checks if the website uses content from 3rd party domains. This isn’t a security vulnerability per-se but might represent in the case that the outside domain is compromised. We recommend that you keep all the necessary resources on your server and load them from there.

3.9 Mixed encryption content

Checks if HTML loads over a secure HTTPS connection but other content, such as images, video content, stylesheets, and scripts, continues to load over an insecure HTTP connection.

3.10 Sensitive Data Crawl

Our scanner engine will analyze the HTTP responses from your target and look for personally identifiable information (PII).

3.11 Find login interfaces

Finds login interfaces and returns the HTML code of the forms.

Did this answer your question?