The HTTP protocol by itself is clear text, meaning that any data that is transmitted via HTTP can be captured and the contents viewed.

To keep data private, and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL), or Transport Layer Security (TLS). When either of these encryption standards are used it is referred to as HTTPS.

Cyber-criminals will often attempt to compromise credentials passed from the client to the server using HTTP. This can be conducted via various different Man-in-The-Middle (MiTM) attacks or through network packet captures.

Scanner discovered that the affected page contains a `password` input, however, the value of the field is not sent to the server utilising HTTPS. Therefore it is possible that any submitted credential may become compromised.

In typical form-based web applications, it is common practice for developers to allow `autocomplete` within the HTML form to improve the usability of the page. With `autocomplete` enabled (default), the browser is allowed to cache previously entered form values.

For legitimate purposes, this allows the user to quickly re-enter the same data when completing the form multiple times.

When `autocomplete` is enabled on either/both the username and password fields, this could allow a cyber-criminal with access to the victim's computer the ability to have the victim's credentials automatically entered as the cyber-criminal visits the affected page.

Scanner has discovered that the affected page contains a form containing a password field that has not disabled `autocomplete`.

The design of many web applications require that users be able to upload files that will either be stored or processed by the receiving web server.

Scanner has flagged this not as a vulnerability, but as a prompt for the penetration tester to conduct further manual testing on the file upload function.

An insecure form-based file upload could allow a cyber-criminal a means to abuse and successfully exploit the server directly, and/or any third party that may later access the file. This can occur through uploading a file containing server side-code (such as PHP) that is then executed when requested by the client.

Concurrent Version System (CVS) and Subversion (SVN) provide a method for application developers to control different versions of their code.

Occasionally, the developer's version or user information can be stored incorrectly within the code and may be visible to the end user (either in the HTML or code comments). As one of the initial steps in information gathering, cyber-criminals will spider a website and using automated methods attempt to discover any CVS/SVN information that may be present in the page.

This will aid them in developing a better understanding of the deployed application (potentially through the disclosure of version information), or it may assist in further information gathering or social engineering attacks.

Using the same automated methods, scanner was able to detect CVS or SVN details stored within the affected page.

Email addresses are typically found on "Contact us" pages, however, they can also be found within scripts or code comments of the application. They are used to provide a legitimate means of contacting an organisation.

As one of the initial steps in information gathering, cyber-criminals will spider a website and using automated methods collect as many email addresses as possible, that they may then use in a social engineering attack.

Using the same automated methods, scanner was able to detect one or more email addresses that were stored within the affected page.

Private, or non-routable, IP addresses are generally used within a home or company network and are typically unknown to anyone outside of that network.

Cyber-criminals will attempt to identify the private IP address range being used by their victim, to aid in collecting further information that could then lead to a possible compromise.

Scanner discovered that the affected page returned a RFC 1918 compliant private IP address and therefore could be revealing sensitive information.

This finding typically requires manual verification to ensure the context is correct, as any private IP address within the HTML body will trigger it.

A common practice when administering web applications is to create a copy/backup of a particular file or directory prior to making any modification to the file. Another common practice is to add an extension or change the name of the original file to signify that it is a backup (examples include `.bak`, `.orig`, `.backup`, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup files by adding common extensions onto files already discovered on the webserver. By analysing the response headers from the server they are able to determine if the backup file exists. These backup files can then assist in the compromise of the web application.

By utilising the same method, the scanner was able to discover a possible backup file.

A common practice when administering web applications is to create a copy/backup of a particular directory prior to making any modification. Another common practice is to add an extension or change the name of the original directory to signify that it is a backup (examples include `.bak`, `.orig`, `.backup`, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup directories by adding common extensions onto directories already discovered on the webserver. By analysing the response headers from the server they are able to determine if a backup directory exists. These backup directories can then assist in the compromise of the web application.

By utilising the same method, scanner was able to discover a possible backup directory.

Scanner has detected a common directory on the remote web server.

Web applications are often made up of multiple files and directories. It is possible that over time some directories may become unreferenced (unused) by the web application and forgotten about by the administrator or developer. Because web applications are built using common frameworks, they contain common directories that can be discovered (independent of server).

During the initial reconnaissance stages of an attack, cyber-criminals will attempt to locate unreferenced directories in the hope that the directory will assist in further compromise of the web application. To achieve this, they will make thousands of requests using word lists containing common names. The response headers from the server will then indicate if the directory exists.

Scanner has detected common sensitive files on the remote web server.

Web applications are often made up of multiple files and directories. It is possible that over time some files may become unreferenced (unused) by the web application and forgotten about by the administrator or developer. Because web applications are built using common frameworks, they contain common files that can be discovered (independent of server).

During the initial reconnaissance stages of an attack, cyber-criminals will attempt to locate unreferenced files in the hope that the file will assist in further compromise of the web application. To achieve this, they will make thousands of requests using word lists containing common filenames. The response headers from the server will then indicate if the file exists.

Scanner detected a common administration interface.

The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the "same origin policy".

URL policy files grant cross-domain permissions for reading data. They permit operations that are not permitted by default. The URL policy file for Silverlight is located, by default, in the root directory of the target server, with the name `crossdomain.xml` (for example, at `www.example.com/crossdomain.xml`).

When a domain is specified in `crossdomain.xml`, the site declares that it is willing to allow the operators of any servers in that domain to obtain any document on the server where the policy file resides.

The `crossdomain.xml` file deployed on this website opens the server to all domains (use of a single asterisk "*" as a pure wildcard is supported).

The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the "same origin policy".

URL policy files grant cross-domain permissions for reading data. They permit operations that are not permitted by default. The URL policy file for Silverlight is located, by default, in the root directory of the target server, with the name `ClientAccessPolicy.xml` (for example, at `www.example.com/ClientAccessPolicy.xml`).

When a domain is specified in `ClientAccessPolicy.xml`, the site declares that it is willing to allow the operators of any servers in that domain to obtain any document on the server where the policy file resides.

The `ClientAccessPolicy.xml` file deployed on this website opens the server to all domains (use of a single asterisk "*" as a pure wildcard is supported) and may allow HTTPS resources to be accessed via HTTP dependant on configuration applied, potentially exposing data that is supposed to be secured via HTTPS to 3rd parties and facilitating man-in-the-middle attacks.

When the `secure` flag is set on a cookie, the browser will prevent it from being sent over a clear text channel (HTTP) and only allow it to be sent when an encrypted channel is used (HTTPS).

The scanner discovered that a cookie was set by the server without the secure flag being set. Although the initial setting of this cookie was via an HTTPS connection, any HTTP link to the same server will result in the cookie being sent in clear text.

Note that if the cookie does not contain sensitive information, the risk of this vulnerability is mitigated.

The HttpOnly flag assists in the prevention of client side-scripts (such as JavaScript) from accessing and using the cookie.

This can help prevent XSS attacks from targeting the cookies holding the client's session token (setting the HttpOnly flag does not prevent, nor safeguard against XSS vulnerabilities themselves).

HTTP by itself is a stateless protocol. Therefore the server is unable to determine which requests are performed by which client, and which clients are authenticated or unauthenticated.

The use of HTTP cookies within the headers, allows a web server to identify each individual client and can therefore determine which clients hold valid authentication, from those that do not. These are known as session cookies.

When a cookie is set by the server (sent the header of an HTTP response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by the browser.

One of these flags represents the host, or domain. for which the cookie can be used.

When the cookie is set for the parent domain, rather than the host, this could indicate that the same cookie could be used to access other hosts within that domain. While there are many legitimate reasons for this, it could also be misconfiguration expanding the possible surface of attacks.

Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages.

The server didn't return an `X-Frame-Options` header which means that this website could be at risk of a clickjacking attack.

The `X-Frame-Options` HTTP response header can be used to indicate whether or not a browser should be allowed to render a page inside a frame or iframe. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

Cross Origin Resource Sharing (CORS) is an HTML5 technology which gives modern web browsers the ability to bypass restrictions implemented by the Same Origin Policy.

The Same Origin Policy requires that both the JavaScript and the page are loaded from the same domain in order to allow JavaScript to interact with the page. This in turn prevents malicious JavaScript being executed when loaded from external domains.

The CORS policy allows the application to specify exceptions to the protections implemented by the browser, and enables the developer to specify allowlisted domains for which external JavaScript is permitted to execute and interact with the page.

The 'Access-Control-Allow-Origin' header is insecure when set to '*' or null, as it allows any domain to perform cross-domain requests and read responses. An attacker could abuse this configuration to retrieve private content from an application which does not use standard authentication mechanisms (for example, an Intranet allowing access from the internal network only).

The HTTP protocol by itself is clear text, meaning that any data that is transmitted via HTTP can be captured and the contents viewed. To keep data private and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). When either of these encryption standards are used, it is referred to as HTTPS.

HTTP Strict Transport Security (HSTS) is an optional response header that can be configured on the server to instruct the browser to only communicate via HTTPS. This will be enforced by the browser even if the user requests a HTTP resource on the same server.

Cyber-criminals will often attempt to compromise sensitive information passed from the client to the server using HTTP. This can be conducted via various Man-in-The-Middle (MiTM) attacks or through network packet captures.

Scanner discovered that the affected application is using HTTPS however does not use the HSTS header.

Web applications occasionally use parameter values to store the address of the page to which the client will be redirected -- for example: `yoursite.com/page.asp?redirect=www.yoursite.com/404.asp`

An unvalidated redirect occurs when the client is able to modify the affected parameter value in the request and thus control the location of the redirection. For example, the following URL `yoursite.com/page.asp?redirect=www.anothersite.com` will redirect to `www.anothersite.com`.

There are several ways a redirection can occur:

1) A response with a 3xx status code will tell the browser to redirect to the URL in the "Location" header

2) A response with a "Refresh" header tells the browser to reload the page after a set interval (which can be 0). The header can take an arbitrary URL parameter to load

3) The HTML <meta> tag can take a "http-equiv" attribute which can be used instead of an HTTP response header. Using this, a "Refresh" can be simulated

4) Javascript is used to redirect the browser to an arbitrary URL

Cyber-criminals will abuse these vulnerabilities in social engineering attacks to get users to unknowingly visit malicious web sites.

The scanner has discovered that the server does not validate the parameter value prior to redirecting the client to the injected value.

The scanner identified some responses with a status code other than the usual 200 (OK), 301 (Moved Permanently), 302 (Found) and 404 (Not Found) codes. These codes can provide useful insights into the behavior of the web application and identify any unexpected responses to be addressed.

The HTTP TRACE method allows a client to send a request to the server, and have the same request sent back in the server's response. This allows the client to determine if the server is receiving the request as expected. Often this method is used for debugging purposes (e.g. to verify that a request arrives unaltered).

On many default installations the TRACE method is still enabled.

While not vulnerable by itself, it does provide a method for cyber attackers to bypass the HTTPOnly cookie flag, and therefore could allow a XSS attack to successfully access a session token.

The scanner has discovered that the affected page permits the HTTP TRACE method.

There are a number of HTTP methods that can be used on a webserver (`OPTIONS`, `HEAD`, `GET`, `POST`, `PUT`, `DELETE` etc.). Each of these methods perform a different function and each have an associated level of risk when their use is permitted on the webserver.

By sending an HTTP OPTIONS request and a direct HTTP request for each method, the scanner discovered the methods that are allowed by the server.

This plugin is raised when the scanner has not been able to authenticate against the web application using the login form credentials provided in the scan policy.

Check the output of the plugin to get an explanation of the issue encountered by the scan.

Publishes the sitemap of the web application as seen by the scan.

The list of all URLs that have been detected during the scan are available as an attachment. For each URL in the sitemap, the following information is provided:

- The first time the URL is detected - The logic used to detect the URL. This information may be found by: crawling rendering the page by a specific plugin - The parent URL requested to detect the URL - If the URL has been requested at least once, information about the response - Whether or not the URL has been queued for audit - If the URL has not been queued for audit, the reason why the URL does not need an audit - Whether or not the URL has been effectively audited - If the URL has not been effectively audited, the reason that the scanner was unable to audit the URL


Reasons for not adding a URL to the audit queue are as follows:

- not_in_domain: The domain of the URL does not match main target URL - scope_configuration: The URL does not match scope include list scan settings - directory_depth: The number of directories in the URL path exceeds the scan configuration setting - exclude_file_extension: The URL file extension matched one entry of the file extension blacklist setting - exclude_path_patterns: The URL matched one entry of the URL exclusion blacklist setting - redundant_path: The number of URLs to be audited with the same path and query string parameters has been reached - request_redirect_limit: The number of HTTP redirects allowed per scan configuration setting has been reached - queue_full: The number of URLs to audit has been reached


If a scan fails to audit a URL that has been queued for audit, reasons for the failure are as follows:

- timeout: The request timed out when trying to retrieve URL contents - filesize_exceeded: URL response exceeded file size limit defined in the scan configuration - scan_timelimit_reached: The URL couldn't be audited before the scan time limit - user_abort: The user stopped the scan before the URL could be audited

Provides scan information and statistics of plugins run.

ID	Name	Product	Family	Published	Severity
98082	Unencrypted Password Form	Web App Scanning	Authentication & Session	3/31/2017	medium
98081	Password Field With Auto-Complete	Web App Scanning	Authentication & Session	3/31/2017	low
98080	Form-based File Upload	Web App Scanning	Web Applications	3/31/2017	info
98079	CVS/SVN User Disclosure	Web App Scanning	Data Exposure	3/31/2017	medium
98078	E-mail Address Disclosure	Web App Scanning	Data Exposure	3/31/2017	info
98077	Private IP Address Disclosure	Web App Scanning	Data Exposure	3/31/2017	info
98074	Backup File	Web App Scanning	Data Exposure	3/31/2017	medium
98073	Backup Directory	Web App Scanning	Data Exposure	3/31/2017	medium
98072	Common Directories Detection	Web App Scanning	Web Servers	3/31/2017	info
98071	Common Files Detection	Web App Scanning	Web Servers	3/31/2017	info
98070	Common Administration Interfaces Detection	Web App Scanning	Web Applications	3/31/2017	info
98068	Insecure Cross-Domain Policy (allow-http-request-headers-from)	Web App Scanning	Web Applications	3/31/2017	low
98067	Insecure Cross-Domain Policy (allow-access-from)	Web App Scanning	Web Applications	3/31/2017	low
98065	Insecure Client-Access Policy	Web App Scanning	Web Applications	3/31/2017	low
98064	Cookie Without Secure Flag Detected	Web App Scanning	HTTP Security Header	3/31/2017	low
98063	Cookie Without HttpOnly Flag Detected	Web App Scanning	HTTP Security Header	3/31/2017	low
98062	Cookie Set For Parent Domain	Web App Scanning	HTTP Security Header	3/31/2017	info
98060	Missing 'X-Frame-Options' Header	Web App Scanning	HTTP Security Header	3/31/2017	low
98057	Insecure 'Access-Control-Allow-Origin' Header	Web App Scanning	HTTP Security Header	3/31/2017	low
98056	Missing HTTP Strict Transport Security Policy	Web App Scanning	HTTP Security Header	3/31/2017	medium
98054	Unvalidated Redirection	Web App Scanning	Web Applications	3/31/2017	medium
98050	Interesting Response	Web App Scanning	Web Applications	3/31/2017	info
98048	HTTP TRACE Allowed	Web App Scanning	Web Servers	3/31/2017	low
98047	Allowed HTTP Methods	Web App Scanning	Web Applications	3/31/2017	info
98034	Login Form Authentication Failed	Web App Scanning	Authentication & Session	3/31/2017	info
98009	Web Application Sitemap	Web App Scanning	General	3/31/2017	info
98000	Scan Information	Web App Scanning	General	3/31/2017	info

Detections

Analytics

Newest Plugins

medium

low

info

medium

info

info

medium

medium

info

info

info

low

low

low

low

low

info

low

low

medium

medium

info

low

info

info

info

info