XSSi

Sensitive Data Exposure via Cross-Site Script Inclusion

Overview of the Vulnerability

Cross-Site Script Inclusion (XSSI) is a client-side attack that uses JavaScript within an authenticated session to leak sensitive data. This sensitive data could be authentication related or user related sensitive data. XSSI can be found on this domain which allows an attacker to control code that is executed within a user’s authenticated session.

Cross-Site Script Inclusion (XSSI) is a vulnerability that arises from the nature of the script tag in HTML. Unlike most resources, which are subject to the Same-Origin Policy (SOP), scripts can be included from different domains. This behavior is intended to facilitate the use of libraries and other resources hosted on different servers but also introduces a potential security risk.

Business Impact

XSSI could lead to data theft and exfiltration through the attacker’s ability to manipulate data. These malicious actions could also result in reputational damage for the business through the impact to customers’ trust.

Key Characteristics of XSSI:

• Bypass of SOP: Scripts are exempt from the Same-Origin Policy, allowing them to be included across domains.

• Data Exposure: An attacker can exploit this behavior to read data loaded via the script tag.

• Impact on Dynamic JavaScript/JSONP: XSSI is particularly relevant for dynamic JavaScript or JSON with Padding (JSONP). These technologies often use "ambient-authority" information (like cookies) for authentication. When a script request is made to a different host, these credentials (e.g., cookies) are automatically included in the request.

• Authentication Token Leakage: If an attacker can trick a user's browser into requesting a script from a server they control, they might be able to access sensitive information contained in these requests.

Types

1. Static JavaScript - This represents the conventional form of XSSI.

2. Static JavaScript with Authentication - This type is distinct because it requires authentication to access.

3. Dynamic JavaScript - Involves JavaScript that dynamically generates content.

4. Non-JavaScript - Refers to vulnerabilities that do not involve JavaScript directly.

The following information is a sumary of https://www.scip.ch/en/?labs.20160414. Check it for further details.

Regular XSSI

In this approach, private information is embedded within a globally accessible JavaScript file. Attackers can identify these files using methods like file reading, keyword searches, or regular expressions. Once located, the script containing private information can be included in malicious content, allowing unauthorized access to sensitive data. An example exploitation technique is shown below:

<script src="https://www.vulnerable-domain.tld/script.js"></script>
<script> alert(JSON.stringify(confidential_keys[0])); </script>

Dynamic-JavaScript-based-XSSI and Authenticated-JavaScript-XSSI

These types of XSSI attacks involve confidential information being dynamically added to the script in response to a user's request. Detection can be performed by sending requests with and without cookies and comparing the responses. If the information differs, it may indicate the presence of confidential information. This process can be automated using tools like the DetectDynamicJS Burp extension.

If confidential data is stored in a global variable, it can be exploited using similar methods to those used in Regular XSSI. However, if the confidential data is included in a JSONP response, attackers can hijack the callback function to retrieve the information. This can be done by either manipulating global objects or setting up a function to be executed by the JSONP response, as demonstrated below:

<script>
      var angular = function () { return 1; };
      angular.callbacks = function () { return 1; };
      angular.callbacks._7 = function (leaked) {
          alert(JSON.stringify(leaked));
      };
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

<script>
      leak = function (leaked) {
          alert(JSON.stringify(leaked));
      };
</script>
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>

For variables not residing in the global namespace, prototype tampering can sometimes be exploited. This technique leverages JavaScript's design, where code interpretation involves traversing the prototype chain to locate the called property. By overriding certain functions, such as Array's slice, attackers can access and leak non-global variables:

Array.prototype.slice = function(){
  // leaks ["secret1", "secret2", "secret3"]
  sendToAttackerBackend(this);
};

Further details on attack vectors can be found in the work of Security Researcher Sebastian Lekies, who maintains a list of vectors.

Non-Script-XSSI

Takeshi Terada's research introduces another form of XSSI, where Non-Script files, such as CSV, are leaked cross-origin by being included as sources in a script tag. Historical instances of XSSI, such as Jeremiah Grossman’s 2006 attack to read a complete Google address book and Joe Walker’s 2007 JSON data leak, highlight the severity of these threats. Additionally, Gareth Heyes describes an attack variant involving UTF-7 encoded JSON to escape the JSON format and execute scripts, effective in certain browsers:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>

Steps to Reproduce

1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP

2. Use a browser to navigate to: {{URL}}

3. Forward the following request to the endpoint:

{{request}}

1. Log into an account and navigate to URL which contains the payload

2. Observe the JavaScript payload being executed

Proof of Concept (PoC)

Below is a screenshot demonstrating the injected JavaScript executing:

{{screenshot}}

Recommendation(s)

There is no single technique to stop XSS from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of XSS. Some best practices include the following:

All user input fields should be sanitized based on what the field is likely to contain. For example, a date field (01/01/2001) should only contain a maximum of 10 characters consisting of numbers and forward slashes. Additionally, drop down or pick lists can be used for allowable inputs to ensure expected values are sent to the server. Use appropriate HTTP response headers to ensure the browser correctly interprets responses. These should be customized specific to the application and its environment. For example:

X-Content-Type-Options: nosniff
Content-Security-Policy: default-src ‘self’; script-src ‘self’

For more information, please see the Open Web Application Security Project (OWASP) guides located at:

• https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

• https://owasp.org/www-community/attacks/xss/