Introduction to Cross-site scripting (XSS)
by Kamil Pabin, posted 16/12/2020
As of 2020, many might think that Cross-site Scripting (XSS) vulnerabilities are well explored and that the vast majority of them are addressed by frameworks we use. However, numerous examples from this year alone show XSS remains an issue, with possibly the most famous XSS vulnerability of the year being found in Google Sheets. In this article, I will take you through the basics of Cross-site Scripting (XSS), focusing on the most common types of XSS attacks and the various ways applications are exposed.
not my code!
XSS is probably one of the most known web application vulnerabilities. At a high-level, it involves injecting malicious code into a 3rd party web page. That malicious code will later be executed when the page is visited by users. Going a little deeper, XSS vulnerabilities can be divided into three main families, each with its own way of compromising an application. Even though cases in each group share similarities, each is unique in its own way. Let’s walk through each family of vulnerability by showing a simple example, and discussing how you can protect your application against such attacks.
A reflected XSS is a specific type of XSS whose malicious script bounces off of another website to the victim’s browser. It is passed in the query, typically, in the URL. It makes exploitation as easy as tricking a user to click on a link.
In 2017 a hacker managed to implement reflected XSS in Google Docs Awarded him a bounty for his trouble!
To simulate how the hacker did this, let’s imagine we have an online shop, and one of the features is search for products by phrase. This search bar might look like one shown in Figure 1.
When we search for specific phrases, we may not get any results (Figure 2). Notice that the product_name is part of the URL
Next, let’s try searching for a phrase with a HTML tag, for example <b>. This time, when we get a response, everything after our search phrase is in bold! This might indicate that the application is vulnerable to XSS attacks.
Attackers are not limited to HTTP GET, they can also inject code inside tag event methods or element class names.
So how do you defend against this kind of attack? Simple, you must URL encode all user input. These are what’s known as HTML entities and are replaced as follows:
Table 1. HTML entities and its replacements
What’s shown here is just the tip of the iceberg. For more detail, I encourage you to read the book written by Securitum (in Polish).
This vulnerability was discovered in Twitter in 2018 and caused a massive tweet storm. The text input field wasn’t secured against XSS resulting in the possibility of compromising the retweet button.
In this example, let’s take the same page for searching for products, but this time the seller has an option to upload a description of a product, using HTML tags.
This allows the seller to use formatting tags so description looks more attractive to site visitors. This description is taken as raw input and stored inside a database, so every time a client visits the product page, it will be rendered.
This could lead to stealing authentication tokens, or in this case an attacker could inject code which automatically buys a product the same second you visit the page. This example is highly exaggerated, but this is just basics, in real-life applications, there could be input fields for names, or help questions for password recovery, which is vulnerable to XSS. So how do you avoid these attacks? All rules from Reflected XSS apply here. If you want to allow users to use some set of HTML tags, you could use sanitizers such as DOMPurify which will automatically get rid of unwanted tags.
DOM Based XSS
Let’s look at the online shop application as an example. We’ve modified the design and now offer an input box for adding a URL to an image that will be added somewhere in a page. Users provide a URL, click the preview button, and the image shows in the product description.
All three examples shown above are highly exaggerated, but its point was to show how each vulnerability works. If you are interested in software security, once again, I highly recommend the book written by Securitum. In the next section, I will describe my experience with software security and my thought process in exploiting vulnerabilities.
Modern front-end frameworks lessen the risk of developing applications that are susceptible to XSS attacks. However, as you can see from the Google and Twitter stories mentioned above, the risk still exists. As developers, we must be aware of these problems waiting for us and to broaden our knowledge. I encourage you to read the book mentioned above and to engage with various online courses and challenges that will build to your understanding of cybersecurity.