These 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 technologies used. 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 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 web server.

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 by requesting a list of known common URL paths. Be aware that this may increase the overall scan duration.

1.9 Security.txt file missing

This test checks for the implementation of a security.txt file found usually at the path /.well-known/security.txt. For more information, you can check this out.

1.10 CORS Misconfiguration

Checks if the website accepts requests from arbitrary origins. If it does, the JavaScript on an attacker-controlled website can make arbitrary requests to the server and read the responses.

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, and 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. This test is one of our more complex tests that uses a real browser to validate that a javascript payload was triggered.

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 make 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 Code Injections (multiple tests)

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

The tests for PHP, Ruby, Perl, Server-Side JavaScript and Python are doing the same thing, but with different payloads tailored for the programming language.

These tests use out-of-band detection by doing requests to a server controller by us thus resulting in a lot fewer false positives.

2.8 Broken Authentication

Broken Authentication tests if a page on the target website is accessible both with the credentials provided and without the credentials thus yielding potential broken access control vulnerabilities. This test runs only if authentication was used on the target as it is required. Please also note that an automated scanner cannot know how sensitive the information on a page is. As a result, this type of vulnerability needs to be manually validated. 

2.9 Log4j Remote Code Execution

This test is for the popular Log4j vulnerability by triggering requests to a DNS server controlled by us with an ID that was included in the payload. This out-of-band approach is a lot less prone to false positives.

2.10 Server-Side Template Injection

Server-Side Template Injection happens when user input is directly incorporated into a template and the resulting string is rendered by the templating engine. The impact ranges from XSS, Arbitrary File Read to Remote Code Execution. Currently, we test for template injection in Freemarker, Thymeleaf, Velocity, Smarty, Jinja, and Django.

2.11 ViewState Remote Code Execution

ViewState is an early attempt by Microsoft to introduce state into HTTP, which is stateless. Microsoft added some security measures to it: a MAC for integrity validation and encryption. When the MAC is disabled, it appears that encryption is disabled as well. If the MAC is disabled, the ViewState will be deserialized automatically. This leads to RCE through deserialization attacks that we test for.

2.12 Client-Side Prototype Pollution

Prototype Pollution is a vulnerability specific to JavaScript, due to how the language implementation works internally. Being an OOP-capable language, JavaScript has classes and objects. An object's class can be accessed using the `__proto__` keyword. The quirky behavior is that one can overwrite/add attributes to the underlying class blueprint and all future instances will use this new value.

This test sends payloads to pollute the base Object via the fragment and query part of an URL and then checks if the base Object has the new attribute. This is all done in a real browser.

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 test 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 cookies 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 by itself but might represent one 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) like emails, SSN, etcetera.

3.11 Find login interfaces

Finds login interfaces and returns the HTML code of the forms so a user can use the Password Auditor on it.