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.