1. Introduction
Historically, Cross-Site Script Inclusion (XSSi) is a vulnerability that is often forgotten by those seeking to develop secure applications, sometimes being completely unknown.
This same feeling of oblivion also permeates the scientific field of cybersecurity, which is currently suffering from a hiatus in the development of relevant research on the subject. As a result, the material available online about XSSi frequently doesn’t correspond to practical reality, due to changes in crucial mechanisms – baselines for vulnerability. In addition, consultation materials for those seeking to understand and test the vulnerability, often used as “cheat sheets”, are also out of date.
As a result, when analyzing the entire universe of available materials on XSSi, there is a feeling that they have “stopped in time”. Therefore, there’s a need for an in-depth study of the current situation and prevalence of vulnerability today.
The purpose of this research was to explore techniques already known and documented by previous researchers, but applied in the context of current browsers, understanding the actual functioning of resource inclusion mechanisms. Additionally, it sought to extrapolate the work already conducted, exploring proposals for practical scenarios and shedding light on discussions regarding the impact of different resource inclusions, which have not yet been discussed by other researchers.
2. Defining XSSi
We can define XSSi not just as a vulnerability, but as a whole class of vulnerabilities that are based on the abuse of similar mechanisms. In short, we can define these vulnerabilities as the inclusion of resources initially designed not to be inserted in the context of a source page in a domain belonging to a malicious agent. The attack vector consists of the user accessing a malicious page which implicitly makes a request to a legitimate domain for the inclusion of these resources, exploiting a pre-existing session by attaching session cookies belonging to the user. The vulnerability occurs locally in the context of the target user’s browser. For the attacker to access the data, manipulation via JavaScript is required.
2.1. Same-origin policy
One of the critical mechanisms for web security in the context of browsers is the same-origin policy, which aims to create isolation between pages from different origins, as isolated contexts, avoiding interaction and violation of privacy between the resources belonging to each context.
An origin is defined by the following: protocol, domain and port. All three must be the same to be considered the same origin. For example: https://sidechannel.blog:443 is the same origin as https://sidechannel.blog:443/en, because in both cases the protocol, domain and port are the same. If you had, for example, http://sidechannel.blog:80, it would be considered a different origin, because the protocol and port are not the same.
In practice, we can see this policy in action in a simple way. On a page, we’ll open another one, belonging to the same origin, as a variable, and try to access its content. Note that this is possible:
Performing the same action but opening a different source page isn’t possible:
Despite its importance, the same-origin policy has some exceptions, for example:
Hyperlinks: navigation by clicking on links is common and is an example for this exception, which consists of referencing and redirecting between pages.
Scripts: external scripts can be included, not limited to JavaScript. Other resources can be treated as scripts by the browser, such as JSON (JavaScript Object Notation).
Media: images are an example of media that can be included as an exception to the same-origin policy.
Forms: one page can make a POST request to another. This exception is the basis for the Cross-Site Request Forgery (CSRF) vulnerability.
2.2. SameSite Cookie
One of the mechanisms commonly used to identify a user session are cookies, which are set by the web application developer and stored locally in the user’s browser. When setting a cookie, attributes can also be set, one of which is “SameSite”, which is responsible for defining the browser’s behavior in relation to the cookie when dealing with cross-origin requests.
The attribute was implemented in the first popular browser on May 25, 2016, with the release of version “51” of Google Chrome, and is now supported by all the most popular browsers. It arose out of a need for a mechanism to prevent Cross-Site Request Forgery (CSRF) attacks, but also reflected Cross-Site Script Inclusion (XSSi), since both are based on the need for cross-origin requests.
The attribute can be assigned the following values:
Strict: the cookie is only sent in requests to the same origin.
Lax: at the time of publication of this article, this is the default value when it is not explicitly declared by the application. It is only sent in cross-requests when browsing from one site to another. For example, when clicking on a link.
None: the cookie will be sent on all requests, with no restrictions on origin. The cookie must be set with the Secure=true attribute.
3. Previous work
Previously, other researchers have explored the subject, serving as a foundation for its development. Let’s take a look at the researchers and the results of their studies.
3.1. Jeremiah Grossman
In 2016, Jeremiah Grossman published on his blog a description of an attack against Gmail, whereby a user’s contact list, stored in a dynamically generated JSON (JavaScript Object Notation) vector, could be compromised.
The attack described consisted of the victim accessing a malicious link containing a request to include this JSON stored under Gmail’s domain, using session cookies, thus allowing the inclusion of this JSON containing user data in the context of the malicious page.
Despite describing an XSSi vulnerability for the first time, Grossman didn’t create the name or the class of vulnerabilities, these facts being attributed to Cristoph Kern in 2007, with the publication of his book “Foundations of Security What Every Programmer Needs to Know”.
3.2. Takeshi Terada
In 2015, Takeshi Terada published his work demonstrating that CSV (Comma-Separated Values) files were also susceptible to exploitation via XSSi, being innovative in demonstrating a target that was not treated as a script by the browser, defining the concept of “Non-Script-XSSi”.
3.3. Sebastian Lekies
Sebastian Lekies was one of the researchers responsible for publishing research in 2015 that was interesting both for the study of vulnerability and the context of exploitation at the time of the study. The publication focused on the study of JavaScript code generated dynamically according to the information of a user previously identified by session cookies.
An empirical study was conducted, consisting of an analysis of the Alexa Top 150 sites, requiring only that the researchers were able to register. After this, a search was conducted for dynamic JavaScript code, followed by an investigation into the possibility of vulnerability due to XSSi. In addition to the article, other material available on the research is the talk given by Lekies to Black Hat in 2016, and the following table with the results of the research is also presented:
Another interesting fact, contained in the research, consists of studying the case of targets containing dynamic but unexploited scripts. This was attributed to two cases: files in which the path was also dynamically generated and therefore unpredictable, or when there was a check on the origin of the request to include that resource.
4. Tests
In order to study XSSi and its application today, the aim of this work, empirical tests were conducted. To do this, two machines stored in the cloud and available via the internet were set up.
The first consists of a purposely vulnerable web application. The application has a login page that generates a cookie with the following attributes: SameSite=none and Secure=true. The application has an authenticated area with the following files: a JSONP file (JSON with padding), a JavaScript file and an image.
The second consists of a web application simulating a malicious page. For each case contained in the vulnerable application, there is an exploitation scenario via XSSi. For both machines, the operating system used was Debian 6.1.76-1 and the web server was Apache 2.4.57. To simulate the user machine, the Windows 11 Enterprise Evaluation 22H2 operating system was used. The browsers used were always in the default configuration after installation.
4.1. Navegador Firefox
At first, it was noticed that the Firefox browser, when in older versions, allowed the vulnerability to occur, something that no longer occurred in more recent versions. Therefore, we sought to define from which version this behavior changed, how it changed and why it changed.
By testing random versions, it was discovered that the behavior changed from version 102.1.0esr, dated July 26, 2022. Previously, inclusions occurred normally:
After that, the inclusion request still occurred, but without the attachment of cookies, making it impossible to exploit the vulnerability:
With the analysis of the release notes, it wasn’t possible to define exactly what was changed in the browser for the change in behavior regarding cookies. After asking around in a Firefox forum, it wasn’t possible to reach a conclusion either.
4.2. Other browsers
After analyzing Firefox, we began studying various popular browsers to understand their behavior. For all cases, the version analyzed was the most recent at the time of the research, as well as using the default settings without any modifications after installation, in a desktop environment.
With the study, two cases were identified: those that allowed the vulnerability to occur and those that didn’t, in a similar behavior to that observed in recent versions of Firefox, making the request but without the use of cookies. Those that allowed the vulnerability were called “vulnerable”, and the results can be seen in the following table:
5. Mitigation
Mitigation of the vulnerability can be divided into two: for the client and for the server. For clients, it’s interesting to use browsers with a higher level of maturity in terms of security and privacy, and basic precautions should always be taken which also help in this case. You should always be wary of unknown links, very advantageous offers, messages with a sense of urgency, etc. In addition, avoid providing personal information to applications, always providing only what is necessary and investigating the level of maturity and security of that application.
In the case of the server, attention should first be paid when creating session cookies, using the “SameSite” attribute correctly and avoiding a very permissive policy, preventing insertion in cross-origin requests. You should also separate JavaScript code from dynamically generated data, using JSON for example. You should also be careful not to use the JSONP (JSON with padding) format, since they are treated as script by the browser and are not protected by the same-origin policy. Static media should also be stored with unpredictable and random names and paths, avoiding the possibility of developing a malicious page to include it.
6. Attack scenarios
By analyzing the previous data, it’s possible to understand attack scenarios in which the vulnerability could occur. These are fictitious, but based on everyday scenarios.
6.1. Personal documents
The fictitious company “Zebra Chemicals” sells controlled chemical products and therefore requires a photo ID from its customers. This is stored on a web server, in a predictable path such as {document number}_doc.jpeg and only accessible externally to the user who owns the document, identified by a misconfigured session cookie.
By accessing a social network belonging to “Zebra Químicos”, a malicious agent identifies a review made by ” Joseph”, a regular buyer for the company. The attacker then searches for Joseph’s document number in a data leak, and uses this information to set up a malicious page targeting Joseph. The attacker sends the victim a message posing as a “Zebra Químicos” salesperson, inducing him to access the malicious page. In this way, Joseph’s document image is compromised.
6.2. Messenger
The “ZebraZap” messenger application uses a list of contacts so that the user can save data about the people they talk to through the application. This data is displayed to the user via a dynamic JavaScript code: when requested, the user is identified by a misconfigured session cookie, and the file is filled with the contact list for that user.
A malicious agent publicly advertises a “ZebraZap” messenger group for sharing online pentest courses, attracting many users to the group. The download is finally made available, consisting of a link to an external domain, justified by the attacker due to a limitation on the size of files allowed on “ZebraZap”. As a result, users who access the link will have their contact list compromised.
7. Conclusion
It can be concluded that, despite the negligence and lack of relevance attributed to the subject, the XSSi vulnerability still represents a source of threat to web applications, depending on errors in the development of the application and successful social engineering.
In addition to traditional scenarios involving the inclusion of scripts and dynamically generated code, static media also represent resources that can be exploited, and care must be taken to protect them.
Today’s mitigation options are broader, giving developers the tools they need to combat the problem without affecting the functionality and usability intended for the application.
References
Christoph Kern, Anita Kesavan, Neil Daswani. Foundations of Security: What Every Programmer Needs to Know.
Gertjan Franken, Tom Van Goethem, Wouter Joosen. Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie
Policies. Available at: <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-franken.pdf>
Jeremiah Grossman. Advanced Web Attack Techniques using GMail. Available at: <https://blog.jeremiahgrossman.com/2006/01/advanced-web-attack-techniques-using.html>
Sebastian Lekies, Ben Stock, Martin Wentzel, Martin Johns. The Unexpected Dangers of Dynamic JavaScript. Available at: <https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lekies.pdf>
Takeshi Terada. Identifier based XSSI attacks. Available at: <https://www.mbsd.jp/Whitepaper/xssi.pdf>
Veit Hailperin, Marc Ruef. Cross-Site Script Inclusion A Fameless but Widespread Web Vulnerability Class. Available at: <https://zenodo.org/records/3521661>
