The complete list of tests performed by the website vulnerability scanner with details on how each test works.
These tests can be configured by selecting the Custom Scan Option.
Don't want to read all this? You can also view the most up-to-date findings on the platform.
Got to https://app.pentest-tools.com/finding_templates, just find the search bar and type in WEBSCAN.
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.