Primer: Introduction to Cross Site Scripting (XSS)
Introduction
This article is one of a collection of primer articles, providing a basic introduction to various topics, for reference in other more in-depth articles. These primer articles are written as people come to security pages from various backgrounds, be it a software engineer who wants to understand an issue they need to fix (or prevent one from occurring in the first place) or a penetration tester with no background in software engineering, who wants to understand and know how to exploit a particular issue.
This primer is regarding Cross Site Scripting (XSS).
Cross Site Scripting (XSS)
History
XSS is, similarly to Cross Site Request Forgery, an old attack, but an extremely common one. XSS has been present in one guise or another across all iterations of the OWASP Top 10 since its inception in 2003 [1, 2, 3, 4, 5, 6]. The OWASP Top 10, being a regularly updated list of the 10 most common web application security issues.
Currently, XSS forms part of the OWASP Top 20 2021, within A03:2021 Injection [1]. Not only has it been present for OWASP's entire existence, it has also occupied the top spot in 2007 [5], the number two spot in 2010 [4], and the number three spot in 2013 [3]. Currently, as part of A03:2021 Injection, again it is in third place [1].
XSS was first identified as an attack that enabled scripts from one site to attack, or read contents, from other sites, and it is this attack that led to the invention of Same Origin Policy (SOP), not CSRF as some believe [7]. However, it has morphed from this original meaning, into any time that an application takes, typically, user-supplied HTML and/or JavaScript information and then sends it back to the browser. Thus, enabling an external user/attacker to inject additional HTML and/or JavaScript into a web application.
Given its prevalence, XSS is an important issue for software engineers and penetration testers alike to understand!
Forms of XSS
XSS comes in three varieties:
- Stored XSS (also called Persistent XSS)
- Reflected XSS (also called Non-Persistent)
- DOM-based XSS
Additionally, there is the concept of something called Self-XSS, which is where a XSS vulnerability requires that a user attacks themselves. So Self-XSS is typically executed via social engineering attacks where a user is tricked into copy/pasting the XSS attack.
Irrespective of the form, the browser is executing malicious code, on behalf of an attacker, because it has no way to distinguish between legitimate and malicious code sent to it.
Stored XSS
Stored XSS is where an attacker can submit their own HTML or JavaScript to an application, and the application then stores the supplied script. Subsequently, whenever a user requests the part of the site that loads that content, the user will be presented with the code provided by the attacker, and the (victim) user's browser will execute the script.
This could be, for example, on a forum where an attacker can submit code as part of a post title or post body content, similarly a product review page, or a service review (e.g. holiday let review), or in fact a username on such a site where usernames are displayed. In fact, anywhere, where a user can submit data that is then presented back to other users.
An important point, it doesn't even have to be from traditional form fields. If the application uses data from HTTP Headers, URL values, hidden input variables that is then stored and returned to be displayed in the browser, it is susceptible to this kind of attack. Note that these other values are trivial to modify/attack by an attacker using a very common hacking or penetration testing tool known as BurpSuite. Modifying such fields is one of the first lessons that a hacker or penetration tester would learn!
A rough attack process is described in the following diagram:
In this kind of flow, the user will need to actively request the page(s) that have the malicious content. How this is achieved would vary on a case-by-case basis. For example, a product review page may always display the most recent x product reviews, thus, anyone looking at that particular product would receive the malicious code. In a highly active forum, this would also be easily achieved if the posting title was inticing enough to click on. If it was in a web-based messaging service, the attack would simply send a message for the target user. Attackers can also send links to the page containing their malicious code to the target user directly.
Reflected XSS
In reflected XSS attacks, the main difference is that the attack is not stored in a back-end database.This necessitates that the attack is something that can be embedded in a URL.This is suprisingly common, for example, consider a website that presents the results of a search query, be it products, hotels, music etc. Something along the lines of:
https://www.somemusicstreamingplatform.com/music/search?q=pink%20floydIf the site then returns a response, perhaps similar to "your search for 'pink floyd' returned the following results:" we would now certainly have reflected user input, whether it's susecptible to XSS is another matter.
Following-on from the above example then, if an attacker were to test for Reflected XSS, they could simply try the following:
https://www.somemusicstreamingplatform.com/music/search?q=test<script>alert(1);</script>If the web page loads and then presents an immediate JavaScript pop-up box, we know this is now a viable attack. The attacker then simply needs to send the victim a URL, and the user simply needs to click on/open the link and they will fall victim to the attack.
The following diagram highlights a typical XSS Reflected attack flow:
DOM-Based XSS
DOM-based XSS differs from the other two varieties (Stored and Reflected) in that the vulnerability lies within the client-side code.
For example, an attacker may be able to submit JavaScript into an form field which is processed by JavaScript code, e.g. a search box which displays back "your search for x returned the following results:" or perhaps a username "The username x already exists" etc, where x is meant to contain benign input, but instead, in the case of an attack it would contain malicious JavaScript.
At first glance, these vulnerabilities would be tricky to exploit, though may be feasible with encoding of payloads combined with social engineering. However, more concerning is where the JavaScript with the vulnerability takes the data from the URL. This would behave just like Reflected XSS in this case. There is a particular subcategory of this kind of attack that is very tricky to deal with, where the point of injection is after an anchor character in the URL.
Anchors, represented by the hash or pound sign (#) represent, typically, a point in the page that the browser can jump to. This jump occurs without any data being sent to the server, e.g.:
https://www.somesite.com/somepage#someAnchorIf JavaScript uses the # value in the URL this can be a particularly insidious location in which to inject an attack. This is because the browser does not send the # value to the server, thus, any networking controls (e.g. Web Application-layer Firewalls (WAF)), or server-side input validation will be unable to detect or prevent attacks injected here - quite simply because the attacks will never reach those controls, and will remain within the browser.
When a user clicks a link such as the above, the browser will send a GET request to:
https://www.somesite.com/somepageThen once it receives the HTTP Response from the server it will simply process the # value.
Why XSS? What is the Impact?
XSS attacks are extremely powerful and have many potential uses. If arbitrary JavaScript can be sent to a victim's browser, it can be used to achieve a number of malicious goals:
- Account & session hijacking (perhaps through the stealing of authentication tokens etc depending on how they are secured etc).
- Key logging / sensitive data exfiltration (perhaps using prototype pollution, or event handlers, or a combination).
- Website defacement (rewriting parts, or all, of the vulnerable website's HTML locally within the browser).
- Broader exploitation of the browser (e.g., through the use of the powerful BeEF platform) [8].
As a result, generally, if you discover an XSS issue it could be considered very easily a high or critical issue in that specific system - obviously, if that system itself is not of great importance that is another matter!
How to Resolve and Prevent XSS Issues
There are a couple of key mechanisms in preventing XSS attacks:
(1) Input validation - always validate input from external systems, even between your system's UI and its back-end. Validation should ideally always ensure that input is in the form it is expected to be in, as opposed to identifying potentially dangerous characters and blocking those. By validating input, this would detect any input that does not conform to the expected input and then prevent the processing of it.
(2) Output sanitization - use encoding, e.g. HTML Entities encoding, to encode data that is being presented in the UI. By sanitizing the data before display, this would ensure that the malicious input of <script> would be converted to <script> which would render the text in the browser such that it is readable to the human eye, as opposed to treating it as code to be executed.
References
[1] - OWASP, 'OWASP Top 10 2021', https://owasp.org/www-project-top-ten/, accessed on 2nd January 2024
[2] - OWASP, 'OWASP Top 10 2017', https://owasp.org/www-project-top-ten/2017/Top_10, accessed on 2nd January 2024
[3] - OWASP, 'OWASP Top 10 2013', https://owasp.org/www-pdf-archive/OWASP_Top_10_-_2013.pdf, accessed on 2nd January 2024
[4] - OWASP, 'OWASP Top 10 2010' https://owasp.org/www-pdf-archive/OWASP_Top_10_-_2010.pdf, accessed on 2nd January 2024
[5] - OWASP, 'OWASP Top 10 2007', https://owasp.org/www-pdf-archive/OWASP_Top_10_2007.pdf, accessed on 2nd January 2024
[6] - Von Ulysses, Wolfgang, 'History of All OWASP Top 10 over the years', Medium, https://medium.com/@dramkumar/history-of-all-owasp-top-10-over-the-years-9470c0adf43d, accessed on 2nd January 2024
[7] - Grossman, Jeremiah, 'The origins of Cross Site Scripting (XSS)', https://blog.jeremiahgrossman.com/2006/07/origins-of-cross-site-scripting-xss.html, accessed on 2nd January 2024
[8] - BeEF Project, 'The Browser Exploitation Framework', https://beefproject.com/, accessed on 2nd January 2024
About the author
https://www.linkedin.com/in/chrisblake/
Chris Blake has over 20 years of experience in the information and cyber security field, and is a passionate and qualified Enterprise Security Architect and Privacy Professional who leads and delivers innovative solutions at Firesand Limited, a company he co-founded in 2016. His specialities include application security, enterprise security architecture, and privacy, with a strong track record of building and implementing ISO 27001 compliant and certified information security practices, application security programmes, and enterprise security architectures. He has a thirst for continual learning and a commitment to excellence, as demonstrated by his academic and professional credentials from prestigious institutions such as the University of Oxford, (ISC)², IAPP, SABSA, The Open Group, and ISACA.
Chris holds an MSc in Software and Systems Security at the University of Oxford, and an array of professional certifications: CISSP, ISSAP, CSSLP, CCSP, SSP.NET, SSP.JAVA, CISA, CISM, CIPP/E, CIPM, CIPT, FIP, SCF, TOGAF, CPSA, and CEH.
Chris' experience spans multiple sectors: Retail & eCommerce; Financial Services, Banking, & Payments; i-Gaming; Energy (Oil & Gas); Property Management & PropTech; and Data Science; as well as Defence.
His areas of interests include: penetration testing; regulation & privacy, including the impact on society; access control in software; security automation in development; application of cryptography; security architecture; risk modelling & analysis; HTTP architecture & web security; IoT Security.