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
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

low

low

low

info

low

low

medium

medium

info

low

info

info

info

info