HTTP response splitting occurs when untrusted data is inserted into the response headers without any sanitisation.

If successful, this allows cyber-criminals to essentially split the HTTP response in two.

This is abused by cyber-criminals injecting CR (Carriage Return -- `/r`) and LF (Line Feed -- `\n`) characters which will then form the split. If the CR or LF characters are not processed by the server then it cannot be exploited.

Along with these characters, cyber-criminals can then construct their own arbitrary response headers and body which would then form the second response. The second response is entirely under their control, allowing for a number of other attacks.

Web applications occasionally use parameter values to store the location of a file which will later be required by the server.

An example of this is often seen in error pages, where the actual file path for the error page is stored in a parameter value -- for example `example.com/error.php?page=404.php`.

A path traversal occurs when the parameter value (ie. path to file being called by the server) can be substituted with the relative path of another resource which is located outside of the applications working directory. The server then loads the resource and includes its contents in the response to the client.

Cyber-criminals will abuse this vulnerability to view files that should otherwise not be accessible.

A very common example of this, on *nix servers, is gaining access to the `/etc/passwd` file in order to retrieve a list of server users. This attack would look like: `yoursite.com/error.php?page=../../../../etc/passwd`

As path traversal is based on the relative path, the payload must first traverse to the file system's root directory, hence the string of `../../../../`.

Scanner discovered that it was possible to substitute a parameter value with a relative path to a common operating system file and have the contents of the file included in the response.

Scanner discovered that the affected site is utilising both HTTP and HTTPS. While the HTML code is served over HTTPS, the server is also serving resources over an unencrypted channel, which can lead to the compromise of data, while providing a false sense of security to the user.

To restrict access to specific pages on a webserver, developers can implement various methods of authentication, therefore only allowing access to clients with valid credentials. There are several forms of authentication that can be used. The simplest forms of authentication are known as 'Basic' and 'Basic Realm'. These methods of authentication have several known weaknesses such as being susceptible to brute force attacks.

Additionally, when utilising the NTLM mechanism in a windows environment, several disclosures of information exist, and any brute force attack occurs against the server's local users, or domain users if the web server is a domain member.

Cyber-criminals will attempt to locate protected pages to gain access to them and also perform brute force attacks to discover valid credentials.

Scanner discovered the following page requires NTLM based basic authentication in order to be accessed.

Detects any known CAPTCHA products being used on a page.

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.

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.

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.

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.

ID	Name	Severity
98101	Response Splitting	medium
98100	Path Traversal	high
98091	Mixed Resource Detection	medium
98088	Exposed Localstart.asp Page	medium
98083	CAPTCHA Detection	info
98080	Form-based File Upload	info
98070	Common Administration Interfaces Detection	info
98068	Insecure Cross-Domain Policy (allow-http-request-headers-from)	low
98067	Insecure Cross-Domain Policy (allow-access-from)	low
98065	Insecure Client-Access Policy	low
98054	Unvalidated Redirection	medium
98050	Interesting Response	info
98047	Allowed HTTP Methods	info

Detections

Analytics

Web Applications Family for Web App Scanning

medium

high

medium

medium

info

info

info

low

low

low

medium

info

info