Scan Remediation

Report

Generated by Burp Suite Enterprise Edition | 2021-06-11 11:50 AM
Site name:
Utah Electronics
Scanned:
Start:
2021-06-10 8:00 PM
End:
2021-06-10 9:20 PM
Duration:
1h 19m
Status:
Completed
Included URLs:
http://vulnerable-website.com/
Scan configurations:
Audit coverage - thorough
Reference:
#120

Issues by severity

High: 8
Medium: 1
Low: 3
Information: 21
Total issues found: 33

Scan statistics

Scanned URLs: 41
Scanned URLs with problems: 0
Total URLs: 41
Requests made: 14827
Number of locations: 38
Network errors: 0

Issues found on https://vulnerable-website.com

URLs By issue type Severity Confidence More detail
Cross-site scripting (reflected) [2]
High Certain >>
High Certain >>
Flash cross-domain policy [1]
High Certain >>
External service interaction (DNS) [1]
High Certain >>
Cross-site scripting (DOM-based) [1]
High Firm >>
Serialized object in HTTP message [2]
High Firm >>
High Firm >>
TLS certificate [1]
Medium Certain >>
Strict transport security not enforced [1]
Low Certain >>
Cross-origin resource sharing [2]
Info Certain >>
Info Certain >>
Cross-origin resource sharing: arbitrary origin trusted [2]
Info Certain >>
Info Certain >>
Input returned in response (reflected) [2]
Info Certain >>
Info Certain >>
Cross-domain Referer leakage [1]
Info Certain >>
Cross-domain script include [1]
Info Certain >>
Browser cross-site scripting filter disabled [2]
Info Certain >>
Info Certain >>
Backup file [1]
Info Certain >>
Robots.txt file [1]
Info Certain >>
Cacheable HTTPS response [1]
Info Certain >>
HTML does not specify charset [3]
Info Certain >>
Info Certain >>
Info Certain >>
Frameable response (potential Clickjacking) [1]
Info Firm >>
Directory listing [1]
Info Firm >>
Path-relative style sheet import [1]
Info Tentative >>

Issues found on http://vulnerable-website.com

URLs By issue type Severity Confidence More detail
Flash cross-domain policy [1]
High Certain >>
Unencrypted communications [1]
Low Certain >>
Vulnerable JavaScript dependency [1]
Low Tentative >>
Robots.txt file [1]
Info Certain >>
Frameable response (potential Clickjacking) [1]
Info Firm >>

More details for https://vulnerable-website.com

Cross-site scripting (reflected)

/xss.php

Issue detail:

The value of the xss request parameter is copied into the HTML document as plain text between tags. The payload weh7i<script>alert(1)</script>qmwp8 was submitted in the xss parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

Issue background

Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site that causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).

The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality that it contains, and the other applications that belong to the same domain and organization. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain that can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organization that owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application and exploiting users' trust in the organization in order to capture credentials for other applications that it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.

Issue remediation

In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:

  • Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
  • User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (&lt; &gt; etc).

In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.

References

Vulnerability classifications

Request:

GET /xss.php?xss=testweh7i%3cscript%3ealert(1)%3c%2fscript%3eqmwp8 HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/xss.php

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:19 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 116 Content-Type: text/html; charset=UTF-8 <!doctype HTML> <html> <body> <a href="?xss=test">click</a> testweh7i<script>alert(1)</script>qmwp8 </body> </html>

Cross-site scripting (reflected)

/xss.php/

Issue detail:

The value of the xss request parameter is copied into the HTML document as plain text between tags. The payload i8rd7<script>alert(1)</script>muocw was submitted in the xss parameter. This input was echoed unmodified in the application's response.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.

Issue background

Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site that causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).

The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality that it contains, and the other applications that belong to the same domain and organization. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain that can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organization that owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application and exploiting users' trust in the organization in order to capture credentials for other applications that it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.

Issue remediation

In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:

  • Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
  • User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (&lt; &gt; etc).

In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.

References

Vulnerability classifications

Request:

GET /xss.php/?xss=testi8rd7%3cscript%3ealert(1)%3c%2fscript%3emuocw HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/xss.php/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:52 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 116 Content-Type: text/html; charset=UTF-8 <!doctype HTML> <html> <body> <a href="?xss=test">click</a> testi8rd7<script>alert(1)</script>muocw </body> </html>

Flash cross-domain policy

/crossdomain.xml

Issue detail:

The application publishes a Flash cross-domain policy which allows access from any domain.

Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.

Issue background

The Flash cross-domain policy controls whether Flash client components running on other domains can perform two-way interaction with the domain that publishes the policy. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially gain full access to the application within the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application that allows access. Any domains that are allowed by the Flash cross-domain policy should be reviewed to determine whether it is appropriate for the application to fully trust both their intentions and security posture.

Issue remediation

Any inappropriate entries in the Flash cross-domain policy file should be removed.

Vulnerability classifications

Request:

GET /crossdomain.xml HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:16 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "53-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 83 Content-Type: application/xml <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

External service interaction (DNS)

/ssrf-dns.php

Issue detail:

It is possible to induce the application to perform server-side DNS lookups of arbitrary domain names.

The payload hk57c7h2m4mmok2z5t3yc9d18sel2c20uolbbz0.burpcollaborator.net was submitted in the host parameter.

The application performed a DNS lookup of the specified domain.

Issue background

External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. However, in many cases, it can indicate a vulnerability with serious consequences.

In cases where DNS-based interactions can be triggered, it is normally possible to trigger interactions using other service types, and these are reported as separate issues. If a payload that specifies a particular service type (e.g. a URL) triggers only a DNS-based interaction, then this strongly indicates that the application attempted to connect using that other service, but was prevented from doing so by egress filters in place at the network layer. The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.

Issue remediation

You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.

If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.

References

Vulnerability classifications

Request:

GET /ssrf-dns.php?host=hk57c7h2m4mmok2z5t3yc9d18sel2c20uolbbz0.burpcollaborator.net HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:58 GMT Server: Apache/2.4.41 (Ubuntu) Content-Length: 0 Content-Type: text/html; charset=UTF-8

Collaborator DNS interaction:

The Collaborator server received a DNS lookup of type A for the domain name hk57c7h2m4mmok2z5t3yc9d18sel2c20uolbbz0.burpcollaborator.net.

The lookup was received from IP address 3.248.186.162 at 2021-Jun-10 12:00:58 UTC.

Cross-site scripting (DOM-based)

/csp/dom.html

Issue detail:

The application may be vulnerable to DOM-based cross-site scripting. Data is read from window.location and passed to document.write().

Issue background

DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.

DOM-based cross-site scripting arises when a script writes controllable data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.

Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.

Issue remediation

The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence.

References

Vulnerability classifications

Request:

GET /csp/dom.html HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "42-5a6c740e3873e" Accept-Ranges: bytes Content-Length: 66 Content-Type: text/html <html> <script> document.write(window.location) </script> </html>

Static analysis:

Data is read from window.location and passed to document.write() via the following statements:

  • document.write(window.location)

Serialized object in HTTP message

/csp/deser.html

Issue detail:

The parameter harvestme appears to contain a serialized Java object.

Issue background

Applications may submit a serialized object in a request parameter. This behavior can expose the application in various ways, including:

  • Any sensitive data contained within the object can be viewed by the user.
  • An attacker may be able to interfere with server-side logic by tampering with the contents of the object and re-serializing it.
  • An attacker may be able to cause unauthorized code execution on the server, by controlling the server-side function that is invoked when the object is processed.

Actual exploitation of any code execution vulnerabilities arising from the application's use of serialized objects will typically require the attacker to have access to the source code of the server-side application. This may mitigate the practical impact of this issue in many situations. However, it is still highly recommended to fix the underlying vulnerability. Vulnerabilities in native deserialization functions often allow practical exploitation without source code access.

Issue remediation

The best way to avoid vulnerabilities that arise from the use of serialized objects is not to pass these in request parameters, or expose them in any other way to the client. Generally, it is possible to transmit application data in plain non-serialized form, and handle it with the same precautions that apply to all client-submitted data. If it is considered unavoidable to place serialized objects into request parameters, then it may be possible to prevent attacks by also placing a server-generated cryptographic signature of the object into the same request, and validating the signature before performing deserialization or other processing on the object.

Vulnerability classifications

Request:

GET /csp/deser.html HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "106-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 262 Content-Type: text/html <html><body><form type='multipart' action='?'><input name='harvestme' value='rO0ABXNyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAAH'></input> <in
Snip

Serialized object in HTTP message

/csp/deser.html

Issue detail:

The parameter harvestme appears to contain a serialized Java object.

Issue background

Applications may submit a serialized object in a request parameter. This behavior can expose the application in various ways, including:

  • Any sensitive data contained within the object can be viewed by the user.
  • An attacker may be able to interfere with server-side logic by tampering with the contents of the object and re-serializing it.
  • An attacker may be able to cause unauthorized code execution on the server, by controlling the server-side function that is invoked when the object is processed.

Actual exploitation of any code execution vulnerabilities arising from the application's use of serialized objects will typically require the attacker to have access to the source code of the server-side application. This may mitigate the practical impact of this issue in many situations. However, it is still highly recommended to fix the underlying vulnerability. Vulnerabilities in native deserialization functions often allow practical exploitation without source code access.

Issue remediation

The best way to avoid vulnerabilities that arise from the use of serialized objects is not to pass these in request parameters, or expose them in any other way to the client. Generally, it is possible to transmit application data in plain non-serialized form, and handle it with the same precautions that apply to all client-submitted data. If it is considered unavoidable to place serialized objects into request parameters, then it may be possible to prevent attacks by also placing a server-generated cryptographic signature of the object into the same request, and validating the signature before performing deserialization or other processing on the object.

Vulnerability classifications

Request:

GET /csp/deser.html?harvestme=rO0ABXNyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAAH&submit=click HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/deser.html

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "106-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 262 Content-Type: text/html <html><body><form type='multipart' action='?'><input name='harvestme' value='rO0ABXNyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAAH'></input> <in
Snip

TLS certificate

/

Issue detail:

The following problem was identified with the server's TLS certificate:
  • The server's certificate is not valid for the server's hostname.
The server presented the following certificates:

Server certificate

Issued to:  portswigger-labs.net, ssl.portswigger-labs.net
Issued by:  R3
Valid from:  Thu Apr 22 22:46:46 UTC 2021
Valid to:  Wed Jul 21 22:46:46 UTC 2021

Certificate chain #1

Issued to:  R3
Issued by:  DST Root CA X3
Valid from:  Wed Oct 07 19:21:40 UTC 2020
Valid to:  Wed Sep 29 19:21:40 UTC 2021

Certificate chain #2

Issued to:  DST Root CA X3
Issued by:  DST Root CA X3
Valid from:  Sat Sep 30 21:12:19 UTC 2000
Valid to:  Thu Sep 30 14:01:15 UTC 2021

Issue background

TLS (or SSL) helps to protect the confidentiality and integrity of information in transit between the browser and server, and to provide authentication of the server's identity. To serve this purpose, the server must present an TLS certificate that is valid for the server's hostname, is issued by a trusted authority and is valid for the current date. If any one of these requirements is not met, TLS connections to the server will not provide the full protection for which TLS is designed.

It should be noted that various attacks exist against TLS in general, and in the context of HTTPS web connections in particular. It may be possible for a determined and suitably-positioned attacker to compromise TLS connections without user detection even when a valid TLS certificate is used.

References

Vulnerability classifications

Strict transport security not enforced

/

Issue detail:

This issue was found in multiple locations under the reported path.

Issue background

The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.

To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic.This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

Issue remediation

The application should instruct web browsers to only access the application using HTTPS. To do this, enable HTTP Strict Transport Security (HSTS) by adding a response header with the name 'Strict-Transport-Security' and the value 'max-age=expireTime', where expireTime is the time in seconds that browsers should remember that the site should only be accessed using HTTPS. Consider adding the 'includeSubDomains' flag if appropriate.

Note that because HSTS is a "trust on first use" (TOFU) protocol, a user who has never accessed the application will never have seen the HSTS header, and will therefore still be vulnerable to SSL stripping attacks. To mitigate this risk, you can optionally add the 'preload' flag to the HSTS header, and submit the domain for review by browser vendors.

References

Vulnerability classifications

Request:

GET /csp/deser.html HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "106-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 262 Content-Type: text/html <html><body><form type='multipart' action='?'><input name='harvestme' value='rO0ABXNyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAAH'></input> <in
Snip

Cross-origin resource sharing

/cors.php

Issue detail:

The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.

If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.

Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.

Issue background

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.

Issue remediation

Any inappropriate domains should be removed from the CORS policy.

References

Vulnerability classifications

Request:

GET /cors.php HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: https://vulnerable-website.com

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:32 GMT Server: Apache/2.4.41 (Ubuntu) Access-Control-Allow-Origin: * Vary: Accept-Encoding Content-Length: 42 Content-Type: text/html; charset=UTF-8 <img src=1 onerror=alert(document.domain)>

Cross-origin resource sharing

/cors.php/

Issue detail:

The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request.

If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.

Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.

Issue background

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by an attacker to exploit the trust relationship and attack the application that allows access. CORS policies on pages containing sensitive information should be reviewed to determine whether it is appropriate for the application to trust both the intentions and security posture of any domains granted access.

Issue remediation

Any inappropriate domains should be removed from the CORS policy.

References

Vulnerability classifications

Request:

GET /cors.php/ HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: https://vulnerable-website.com

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:01:05 GMT Server: Apache/2.4.41 (Ubuntu) Access-Control-Allow-Origin: * Vary: Accept-Encoding Content-Length: 42 Content-Type: text/html; charset=UTF-8 <img src=1 onerror=alert(document.domain)>

Cross-origin resource sharing: arbitrary origin trusted

/cors.php

Issue detail:

The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request that allows access from any domain.

The application allowed access from the requested origin https://ikgxbigkitxt.com

If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.

Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.

Issue background

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.

If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to bypass any IP-based access controls by proxying through users' browsers.

Issue remediation

Rather than using a wildcard or programmatically verifying supplied origins, use a whitelist of trusted domains.

References

Vulnerability classifications

Request:

GET /cors.php HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: https://ikgxbigkitxt.com

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:32 GMT Server: Apache/2.4.41 (Ubuntu) Access-Control-Allow-Origin: * Vary: Accept-Encoding Content-Length: 42 Content-Type: text/html; charset=UTF-8 <img src=1 onerror=alert(document.domain)>

Cross-origin resource sharing: arbitrary origin trusted

/cors.php/

Issue detail:

The application implements an HTML5 cross-origin resource sharing (CORS) policy for this request that allows access from any domain.

The application allowed access from the requested origin https://eehepuwjphrg.com

If the application relies on network firewalls or other IP-based access controls, this policy is likely to present a security risk.

Since the Vary: Origin header was not present in the response, reverse proxies and intermediate servers may cache it. This may enable an attacker to carry out cache poisoning attacks.

Issue background

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is fine-grained and can apply access controls per-request based on the URL and other features of the request.

Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by third-party web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.

If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to bypass any IP-based access controls by proxying through users' browsers.

Issue remediation

Rather than using a wildcard or programmatically verifying supplied origins, use a whitelist of trusted domains.

References

Vulnerability classifications

Request:

GET /cors.php/ HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Origin: https://eehepuwjphrg.com

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:01:05 GMT Server: Apache/2.4.41 (Ubuntu) Access-Control-Allow-Origin: * Vary: Accept-Encoding Content-Length: 42 Content-Type: text/html; charset=UTF-8 <img src=1 onerror=alert(document.domain)>

Input returned in response (reflected)

/xss.php

Issue detail:

The value of the xss request parameter is copied into the application's response.

Issue background

Reflection of input arises when data is copied from a request and echoed into the application's immediate response.

Input being returned in application responses is not a vulnerability in its own right. However, it is a prerequisite for many client-side vulnerabilities, including cross-site scripting, open redirection, content spoofing, and response header injection. Additionally, some server-side vulnerabilities such as SQL injection are often easier to identify and exploit when input is returned in responses. In applications where input retrieval is rare and the environment is resistant to automated testing (for example, due to a web application firewall), it might be worth subjecting instances of it to focused manual testing.

Vulnerability classifications

Request:

GET /xss.php?xss=test4oadh2sb07 HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/xss.php

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:19 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 91 Content-Type: text/html; charset=UTF-8 <!doctype HTML> <html> <body> <a href="?xss=test">click</a> test4oadh2sb07 </body> </html>

Input returned in response (reflected)

/xss.php/

Issue detail:

The value of the xss request parameter is copied into the application's response.

Issue background

Reflection of input arises when data is copied from a request and echoed into the application's immediate response.

Input being returned in application responses is not a vulnerability in its own right. However, it is a prerequisite for many client-side vulnerabilities, including cross-site scripting, open redirection, content spoofing, and response header injection. Additionally, some server-side vulnerabilities such as SQL injection are often easier to identify and exploit when input is returned in responses. In applications where input retrieval is rare and the environment is resistant to automated testing (for example, due to a web application firewall), it might be worth subjecting instances of it to focused manual testing.

Vulnerability classifications

Request:

GET /xss.php/?xss=test4c1t350x1p HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/xss.php/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:52 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 91 Content-Type: text/html; charset=UTF-8 <!doctype HTML> <html> <body> <a href="?xss=test">click</a> test4c1t350x1p </body> </html>

Cross-domain Referer leakage

/mavo_dom_based_xss/

Issue detail:

The page was loaded from a URL containing a query string:
  • https://vulnerable-website.com/mavo_dom_based_xss/
The response contains the following links to other domains:
  • https://get.mavo.io/mavo.css
  • https://plugins.mavo.io/markdown/mavo-markdown.js
  • https://plugins.mavo.io/yaml/mavo-yaml.js
  • https://www.w3.org/Mail/flatten/index?subject={comment}&list=www-style

Issue background

When a web browser makes a request for a resource, it typically adds an HTTP header, called the "Referer" header, indicating the URL of the resource from which the request originated. This occurs in numerous situations, for example when a web page loads an image or script, or when a user clicks on a link or submits a form.

If the resource being requested resides on a different domain, then the Referer header is still generally included in the cross-domain request. If the originating URL contains any sensitive information within its query string, such as a session token, then this information will be transmitted to the other domain. If the other domain is not fully trusted by the application, then this may lead to a security compromise.

You should review the contents of the information being transmitted to other domains, and also determine whether those domains are fully trusted by the originating application.

Today's browsers may withhold the Referer header in some situations (for example, when loading a non-HTTPS resource from a page that was loaded over HTTPS, or when a Refresh directive is issued), but this behavior should not be relied upon to protect the originating URL from disclosure.

Note also that if users can author content within the application then an attacker may be able to inject links referring to a domain they control in order to capture data from URLs used within the application.

Issue remediation

Applications should never transmit any sensitive information within the URL query string. In addition to being leaked in the Referer header, such information may be logged in various locations and may be visible on-screen to untrusted parties. If placing sensitive information in the URL is unavoidable, consider using the Referer-Policy HTTP header to reduce the chance of it being disclosed to third parties.

References

Vulnerability classifications

Request:

GET /mavo_dom_based_xss/?spec=css-images&doc=cr-2012 HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/mavo_dom_based_xss/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:21 GMT Etag: "2955-5a6c740e972e0-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 10581 Content-Type: text/html <!DOCTYPE html> <html lang="en" mv-expressions="{ }"> <head> <meta charset="UTF-8"> <title>Disposition of Comments</title> <link rel="stylesheet" href="https://get.mavo.io/mavo.css"> <link rel="stylesheet" href="issues.css">
Snip
</div> <script src="https://plugins.mavo.io/yaml/mavo-yaml.js"></script> <script src="https://plugins.mavo.io/markdown/mavo-markdown.js"></script>
Snip

Cross-domain script include

/mavo_dom_based_xss/

Issue detail:

The response dynamically includes the following scripts from other domains:
  • https://plugins.mavo.io/markdown/mavo-markdown.js
  • https://plugins.mavo.io/yaml/mavo-yaml.js

Issue background

When an application includes a script from an external domain, this script is executed by the browser within the security context of the invoking application. The script can therefore do anything that the application's own scripts can do, such as accessing application data and performing actions within the context of the current user.

If you include a script from an external domain, then you are trusting that domain with the data and functionality of your application, and you are trusting the domain's own security to prevent an attacker from modifying the script to perform malicious actions within your application.

Issue remediation

Scripts should ideally not be included from untrusted domains. Applications that rely on static third-party scripts should consider using Subresource Integrity to make browsers verify them, or copying the contents of these scripts onto their own domain and including them from there. If that is not possible (e.g. for licensing reasons) then consider reimplementing the script's functionality within application code.

References

Vulnerability classifications

Request:

GET /mavo_dom_based_xss/?spec=css-images&doc=cr-2012 HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/mavo_dom_based_xss/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:21 GMT Etag: "2955-5a6c740e972e0-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 10581 Content-Type: text/html <!DOCTYPE html> <html lang="en" mv-expressions="{ }"> <head> <meta charset="UTF-8"> <title>Disposition of Comments</title> <link rel="stylesheet" href="https://get.mavo.io/mavo.css"> <link rel="s
Snip
</div> <script src="https://plugins.mavo.io/yaml/mavo-yaml.js"></script> <script src="https://plugins.mavo.io/markdown/mavo-markdown.js"></script>
Snip

Browser cross-site scripting filter disabled

/csp/csp.php

Issue description

Some browsers, including Internet Explorer, contain built-in filters designed to protect against cross-site scripting (XSS) attacks. Applications can instruct browsers to disable this filter by setting the following response header:

X-XSS-Protection: 0

This behavior does not in itself constitute a vulnerability; in some cases XSS filters may themselves be leveraged to perform attacks against application users. However, in typical situations XSS filters do provide basic protection for application users against some XSS vulnerabilities in applications. The presence of this header should be reviewed to establish whether it affects the application's security posture.

Issue remediation

Review whether the application needs to disable XSS filters. In most cases you can gain the protection provided by XSS filters without the associated risks by using the following response header:

X-XSS-Protection: 1; mode=block

When this header is set, browsers that detect an XSS attack will simply render a blank page instead of attempting to sanitize the injected script. This behavior is considerably less likely to introduce new security issues.

References

Vulnerability classifications

Request:

GET /csp/csp.php HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Content-Security-Policy: script-src 'self' X-Xss-Protection: 0 Vary: Accept-Encoding Content-Length: 55 Content-Type: text/html; charset=UTF-8 <html> <head> </head> <body> </body> </html>

Browser cross-site scripting filter disabled

/utf-16be/csp/

Issue description

Some browsers, including Internet Explorer, contain built-in filters designed to protect against cross-site scripting (XSS) attacks. Applications can instruct browsers to disable this filter by setting the following response header:

X-XSS-Protection: 0

This behavior does not in itself constitute a vulnerability; in some cases XSS filters may themselves be leveraged to perform attacks against application users. However, in typical situations XSS filters do provide basic protection for application users against some XSS vulnerabilities in applications. The presence of this header should be reviewed to establish whether it affects the application's security posture.

Issue remediation

Review whether the application needs to disable XSS filters. In most cases you can gain the protection provided by XSS filters without the associated risks by using the following response header:

X-XSS-Protection: 1; mode=block

When this header is set, browsers that detect an XSS attack will simply render a blank page instead of attempting to sanitize the injected script. This behavior is considerably less likely to introduce new security issues.

References

Vulnerability classifications

Request:

GET /utf-16be/csp/ HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Content-Security-Policy: default-src 'self' X-Xss-Protection: 0 Vary: Accept-Encoding Content-Length: 81 Content-Type: text/html; charset='' <!doctype HTML><html> <head> <title>Test</title> </head> <body> </body> </html>

Backup file

/xss.php

Issue description

Publicly accessible backups and outdated copies of files can provide attackers with extra attack surface. Depending on the server configuration and file type, they may also expose source code, configuration details, and other information intended to remain secret.

Issue remediation

Review the file to identify whether it's intended to be publicly accessible, and remove it from the server's web root if it isn't. It may also be worth auditing the server contents to find other outdated files, and taking measures to prevent the problem from recurring.

References

Vulnerability classifications

Request 1:

GET /xss.php.bak?xss=test HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/xss.php

Response 1:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:39 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:21 GMT Etag: "4c-5a6c740f3f263" Accept-Ranges: bytes Content-Length: 76 Content-Type: application/x-trash <!doctype HTML> <html> <body> <?php echo($_GET['xss']); ?> </body> </html>

Request 2:

GET /rpvq.php.bak?xss=test HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/xss.php

Response 2:

HTTP/2 404 Not Found Date: Thu, 10 Jun 2021 12:00:39 GMT Server: Apache/2.4.41 (Ubuntu) Content-Length: 285 Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL was not found on this server.</p> <hr> <address>Apache/2.4.41 (Ubuntu) Server at vulnerable-website.com Port 443</address> </body>
Snip

Robots.txt file

/robots.txt

Issue detail:

The web server contains a robots.txt file.

Issue background

The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index.

The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.

Issue remediation

The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honor the file's instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorized access.

Vulnerability classifications

Request:

GET /robots.txt HTTP/1.1 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close

Response:

HTTP/1.1 200 OK Date: Thu, 10 Jun 2021 12:00:16 GMT Server: Apache/2.4.41 (Ubuntu) Upgrade: h2 Connection: Upgrade, close Last-Modified: Mon, 22 Mar 2021 15:22:59 GMT ETag: "14f-5be21a417220f-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 335 Content-Type: text/plain User-agent: Browsershots Disallow: User-agent: * Disallow: /csp/ Disallow: /fmnt.php Disallow: /ssrf-dns.php?host=localhost Disallow: /fmnt.php?url=portswigger.net/ Disallow: /utf-16be/csp Disallow: /
Snip

Cacheable HTTPS response

/

Issue detail:

This issue was found in multiple locations under the reported path.

Issue background

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.

Issue remediation

Applications should return caching directives instructing browsers not to store local copies of any sensitive data. Often, this can be achieved by configuring the web server to prevent caching for relevant paths within the web root. Alternatively, most web development platforms allow you to control the server's caching directives from within individual scripts. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content:

  • Cache-control: no-store
  • Pragma: no-cache

Vulnerability classifications

Request 1:

GET /fmnt.php/ HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response 1:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 334 Content-Type: text/html; charset=UTF-8 <!doctype HTML> <html> <head> <meta name="robots" content="noindex, nofollow" /> </head> <body> <script> var x = /x=(.+)/.exec(window.location.search); if(x) { window.location = 'https://'+ x[1]; }
Snip

Request 2:

GET /csp/?C=M%3bO=A HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response 2:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 1530 Content-Type: text/html;charset=UTF-8 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html> <head> <title>Index of /csp</title> </head> <body> <h1>Index of /csp</h1> <table> <tr><th valign="top"><img src="/icons/blank.g
Snip

Request 3:

GET /csp/deser.html HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response 3:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "106-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 262 Content-Type: text/html <html><body><form type='multipart' action='?'><input name='harvestme' value='rO0ABXNyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAAH'></input> <in
Snip

HTML does not specify charset

/csp/deser.html

Issue description

If a response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.

In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.

Issue remediation

For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognized character set, for example charset=ISO-8859-1.

Vulnerability classifications

Request:

GET /csp/deser.html HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "106-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 262 Content-Type: text/html <html><body><form type='multipart' action='?'><input name='harvestme' value='rO0ABXNyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAAH'></input> <in
Snip

HTML does not specify charset

/csp/dom.html

Issue description

If a response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.

In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.

Issue remediation

For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognized character set, for example charset=ISO-8859-1.

Vulnerability classifications

Request:

GET /csp/dom.html HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:20 GMT Etag: "42-5a6c740e3873e" Accept-Ranges: bytes Content-Length: 66 Content-Type: text/html <html> <script> document.write(window.location) </script> </html>

HTML does not specify charset

/utf-16be/csp/

Issue description

If a response states that it contains HTML content but does not specify a character set, then the browser may analyze the HTML and attempt to determine which character set it appears to be using. Even if the majority of the HTML actually employs a standard character set such as UTF-8, the presence of non-standard characters anywhere in the response may cause the browser to interpret the content using a different character set. This can have unexpected results, and can lead to cross-site scripting vulnerabilities in which non-standard encodings like UTF-7 can be used to bypass the application's defensive filters.

In most cases, the absence of a charset directive does not constitute a security flaw, particularly if the response contains static content. You should review the contents of affected responses, and the context in which they appear, to determine whether any vulnerability exists.

Issue remediation

For every response containing HTML content, the application should include within the Content-type header a directive specifying a standard recognized character set, for example charset=ISO-8859-1.

Vulnerability classifications

Request:

GET /utf-16be/csp/ HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Content-Security-Policy: default-src 'self' X-Xss-Protection: 0 Vary: Accept-Encoding Content-Length: 81 Content-Type: text/html; charset='' <!doctype HTML><html> <head> <title>Test</title> </head> <body> </body> </html>

Frameable response (potential Clickjacking)

/

Issue detail:

This issue was found in multiple locations under the reported path.

Issue background

If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.

Note that some applications attempt to prevent these attacks from within the HTML page itself, using "framebusting" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.

You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application.

Issue remediation

To effectively prevent framing attacks, the application should return a response header with the name X-Frame-Options and the value DENY to prevent framing altogether, or the value SAMEORIGIN to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.

References

Vulnerability classifications

Request 1:

GET /csp/?C=M%3bO=A HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response 1:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 1530 Content-Type: text/html;charset=UTF-8 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html> <head> <title>Index of /csp</title> </head> <body> <h1>Index of /csp</h1> <table> <tr><th valign="top"><img src="/icons/blank.g
Snip

Request 2:

GET /mavo_dom_based_xss/?spec=css-images&doc=cr-2012 HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/mavo_dom_based_xss/

Response 2:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:21 GMT Etag: "2955-5a6c740e972e0-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 10581 Content-Type: text/html <!DOCTYPE html> <html lang="en" mv-expressions="{ }"> <head> <meta charset="UTF-8"> <title>Disposition of Comments</title> <link rel="stylesheet" href="https://get.mavo.io/mavo.css"> <link rel="s
Snip

Request 3:

GET /cors.php HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response 3:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Access-Control-Allow-Origin: * Vary: Accept-Encoding Content-Length: 42 Content-Type: text/html; charset=UTF-8 <img src=1 onerror=alert(document.domain)>

Directory listing

/csp/

Issue description

Web servers can be configured to automatically list the contents of directories that do not have an index page present. This can aid an attacker by enabling them to quickly identify the resources at a given path, and proceed directly to analyzing and attacking those resources. It particularly increases the exposure of sensitive files within the directory that are not intended to be accessible to users, such as temporary files and crash dumps.

Directory listings themselves do not necessarily constitute a security vulnerability. Any sensitive resources within the web root should in any case be properly access-controlled, and should not be accessible by an unauthorized party who happens to know or guess the URL. Even when directory listings are disabled, an attacker may guess the location of sensitive files using automated tools.

Issue remediation

There is not usually any good reason to provide directory listings, and disabling them may place additional hurdles in the path of an attacker. This can normally be achieved in two ways:

  • Configure your web server to prevent directory listings for all paths beneath the web root;
  • Place into each directory a default file (such as index.htm) that the web server will display instead of returning a directory listing.

Vulnerability classifications

Request:

GET /csp/?C=M%3bO=A HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/csp/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Vary: Accept-Encoding Content-Length: 1530 Content-Type: text/html;charset=UTF-8 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html> <head> <title>Index of /csp</title> </head> <body> <h1>Index of /csp</h1> <table> <tr><th valign="top"><img src="/icons/blank.g
Snip
<th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th><a href="?C=D;O=A">Description</a>
Snip
<td><a href="/">Parent Directory</a>
Snip

Path-relative style sheet import

/mavo_dom_based_xss/

Issue detail:

The application may be vulnerable to path-relative style sheet import (PRSSI) attacks. The response contains a path-relative style sheet import, and so condition 1 for an exploitable vulnerability is present (see issue background). The response can also be made to render in a browser's quirks mode. The page does not contain a doctype directive, and so it will always be rendered in quirks mode. Further, the response does not prevent itself from being framed, so an attacker can frame the response within a page that they control, to force it to be rendered in quirks mode. (Note that this technique is IE-specific and due to P3P restrictions might sometimes limit the impact of a successful attack.) This means that condition 3 for an exploitable vulnerability is probably present if condition 2 is present.

Burp was not able to confirm that the other conditions hold, and you should manually investigate this issue to confirm whether they do hold.

Issue background

Path-relative style sheet import vulnerabilities arise when the following conditions hold:

  1. A response contains a style sheet import that uses a path-relative URL (for example, the page at "/original-path/file.php" might import "styles/main.css").
  2. When handling requests, the application or platform tolerates superfluous path-like data following the original filename in the URL (for example, "/original-path/file.php/extra-junk/"). When superfluous data is added to the original URL, the application's response still contains a path-relative stylesheet import.
  3. The response in condition 2 can be made to render in a browser's quirks mode, either because it has a missing or old doctype directive, or because it allows itself to be framed by a page under an attacker's control.
  4. When a browser requests the style sheet that is imported in the response from the modified URL (using the URL "/original-path/file.php/extra-junk/styles/main.css"), the application returns something other than the CSS response that was supposed to be imported. Given the behavior described in condition 2, this will typically be the same response that was originally returned in condition 1.
  5. An attacker has a means of manipulating some text within the response in condition 4, for example because the application stores and displays some past input, or echoes some text within the current URL.

Given the above conditions, an attacker can execute CSS injection within the browser of the target user. The attacker can construct a URL that causes the victim's browser to import as CSS a different URL than normal, containing text that the attacker can manipulate.

Being able to inject arbitrary CSS into the victim's browser may enable various attacks, including:

  • Executing arbitrary JavaScript using IE's expression() function.
  • Using CSS selectors to read parts of the HTML source, which may include sensitive data such as anti-CSRF tokens.
  • Capturing any sensitive data within the URL query string by making a further style sheet import to a URL on the attacker's domain, and monitoring the incoming Referer header.

Issue remediation

The root cause of the vulnerability can be resolved by not using path-relative URLs in style sheet imports. Aside from this, attacks can also be prevented by implementing all of the following defensive measures:

  • Setting the HTTP response header "X-Frame-Options: deny" in all responses. One method that an attacker can use to make a page render in quirks mode is to frame it within their own page that is rendered in quirks mode. Setting this header prevents the page from being framed.
  • Setting a modern doctype (e.g. "<!doctype html>") in all HTML responses. This prevents the page from being rendered in quirks mode (unless it is being framed, as described above).
  • Setting the HTTP response header "X-Content-Type-Options: nosniff" in all responses. This prevents the browser from processing a non-CSS response as CSS, even if another page loads the response via a style sheet import.

References

Vulnerability classifications

Request:

GET /mavo_dom_based_xss/?spec=css-images&doc=cr-2012 HTTP/2 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: https://vulnerable-website.com/mavo_dom_based_xss/

Response:

HTTP/2 200 OK Date: Thu, 10 Jun 2021 12:00:13 GMT Server: Apache/2.4.41 (Ubuntu) Last-Modified: Fri, 29 May 2020 10:53:21 GMT Etag: "2955-5a6c740e972e0-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 10581 Content-Type: text/html <!DOCTYPE html> <html lang="en" mv-expressions="{ }"> <head> <meta charset="UTF-8"> <title>Disposition of Comments</title> <link rel="stylesheet" href="https://get.mavo.io/mavo.css"> <link rel="stylesheet" href="issues.css"> <script src="mavo.js">
Snip

More details for http://vulnerable-website.com

Flash cross-domain policy

/crossdomain.xml

Issue detail:

The application publishes a Flash cross-domain policy which allows access from any domain.

Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.

Issue background

The Flash cross-domain policy controls whether Flash client components running on other domains can perform two-way interaction with the domain that publishes the policy. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially gain full access to the application within the security context of the logged in user.

Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application that allows access. Any domains that are allowed by the Flash cross-domain policy should be reviewed to determine whether it is appropriate for the application to fully trust both their intentions and security posture.

Issue remediation

Any inappropriate entries in the Flash cross-domain policy file should be removed.

Vulnerability classifications

Request:

GET /crossdomain.xml HTTP/1.1 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close

Response:

HTTP/1.1 200 OK Date: Thu, 10 Jun 2021 12:00:16 GMT Server: Apache/2.4.41 (Ubuntu) Upgrade: h2,h2c Connection: Upgrade, close Last-Modified: Fri, 29 May 2020 10:53:20 GMT ETag: "53-5a6c740e3873e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 83 Content-Type: application/xml <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

Unencrypted communications

/

Issue description

The application allows users to connect to it over unencrypted connections. An attacker suitably positioned to view a legitimate user's network traffic could record and monitor their interactions with the application and obtain any information the user supplies. Furthermore, an attacker able to modify traffic could use the application as a platform for attacks against its users and third-party websites. Unencrypted connections have been exploited by ISPs and governments to track users, and to inject adverts and malicious JavaScript. Due to these concerns, web browser vendors are planning to visually flag unencrypted connections as hazardous.

To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

Please note that using a mixture of encrypted and unencrypted communications is an ineffective defense against active attackers, because they can easily remove references to encrypted resources when these references are transmitted over an unencrypted connection.

Issue remediation

Applications should use transport-level encryption (SSL/TLS) to protect all communications passing between the client and the server. The Strict-Transport-Security HTTP header should be used to ensure that clients refuse to access the server over an insecure connection.

References

Vulnerability classifications

Vulnerable JavaScript dependency

/index_files/jquery-2.js

Issue detail:

We observed a vulnerable JavaScript library.

We detected jquery version 2.2.0, which has the following vulnerabilities:

  • CVE-2015-9251: 3rd party CORS request may execute
  • CVE-2019-11358: jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution
  • CVE-2020-11022: Regex in its jQuery.htmlPrefilter sometimes may introduce XSS
  • CVE-2020-11023: Regex in its jQuery.htmlPrefilter sometimes may introduce XSS

Issue background

The use of third-party JavaScript libraries can introduce a range of DOM-based vulnerabilities, including some that can be used to hijack user accounts like DOM-XSS.

Common JavaScript libraries typically enjoy the benefit of being heavily audited. This may mean that bugs are quickly identified and patched upstream, resulting in a steady stream of security updates that need to be applied. Although it may be tempting to ignore updates, using a library with missing security patches can make your website exceptionally easy to exploit. Therefore, it's important to ensure that any available security updates are applied promptly.

Some library vulnerabilities expose every application that imports the library, but others only affect applications that use certain library features. Accurately identifying which library vulnerabilities apply to your website can be difficult, so we recommend applying all available security updates regardless.

Issue remediation

Develop a patch-management strategy to ensure that security updates are promptly applied to all third-party libraries in your application. Also, consider reducing your attack surface by removing any libraries that are no longer in use.

Vulnerability classifications

Request:

GET /index_files/jquery-2.js HTTP/1.1 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0 Referer: http://vulnerable-website.com/

Response:

HTTP/1.1 200 OK Date: Thu, 10 Jun 2021 12:00:15 GMT Server: Apache/2.4.41 (Ubuntu) Upgrade: h2,h2c Connection: Upgrade, close Last-Modified: Fri, 29 May 2020 10:53:20 GMT ETag: "14e59-5a6c740e3a67e-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 85593 Content-Type: application/javascript /*! jQuery v2.2.0 | (c) jQuery Foundation | jquery.org/license */ !function(a,b){"object"==typeof module&&"object"==typeof module.exports?module.exports=a.document?b(a,!0):function(a){if(!a.document)throw new Error("j
Snip

Robots.txt file

/robots.txt

Issue detail:

The web server contains a robots.txt file.

Issue background

The file robots.txt is used to give instructions to web robots, such as search engine crawlers, about locations within the web site that robots are allowed, or not allowed, to crawl and index.

The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.

Issue remediation

The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons. You should not assume that all web robots will honor the file's instructions. Rather, assume that attackers will pay close attention to any locations identified in the file. Do not rely on robots.txt to provide any kind of protection over unauthorized access.

Vulnerability classifications

Request:

GET /robots.txt HTTP/1.1 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close

Response:

HTTP/1.1 200 OK Date: Thu, 10 Jun 2021 12:00:16 GMT Server: Apache/2.4.41 (Ubuntu) Upgrade: h2,h2c Connection: Upgrade, close Last-Modified: Mon, 22 Mar 2021 15:22:59 GMT ETag: "14f-5be21a417220f-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 335 Content-Type: text/plain User-agent: Browsershots Disallow: User-agent: * Disallow: /csp/ Disallow: /fmnt.php Disallow: /ssrf-dns.php?host=localhost Disallow: /fmnt.php?url=portswigger.net/ Disallow: /utf-16be/csp Disallow: /
Snip

Frameable response (potential Clickjacking)

/

Issue description

If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.

Note that some applications attempt to prevent these attacks from within the HTML page itself, using "framebusting" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.

You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application.

Issue remediation

To effectively prevent framing attacks, the application should return a response header with the name X-Frame-Options and the value DENY to prevent framing altogether, or the value SAMEORIGIN to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.

References

Vulnerability classifications

Request:

GET / HTTP/1.1 Host: vulnerable-website.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en-US,en-GB;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Connection: close Cache-Control: max-age=0

Response:

HTTP/1.1 200 OK Date: Thu, 10 Jun 2021 12:00:12 GMT Server: Apache/2.4.41 (Ubuntu) Upgrade: h2,h2c Connection: Upgrade, close Vary: Accept-Encoding Content-Length: 2719 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <html><head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="vi
Snip