Threat Analysis: What Is XSS?

Welcome to Cross-Site Scripting session.

In this first part, we will focus on threat analysis. We will take our time to discuss cross-site scripting details. Then we will discuss how the system can be harmed, then the impact of successful exploitation and give you some insights to identify who may want to harm your system. XSS, or Cross-Site Scripting, is a type of injection in which malicious scripts are injected into otherwise benign interested websites. We have already discussed injection flaws, but cross-site scripting was so prevalent and specific that it was given its one category in the OWASP Top 10. It has remained in the top 10 for several editions.

Although it has dropped from third to seventh in the 2017 Top 10, it is still the second most prevalent issue affecting around two thirds of all applications. Let’s see how it works. In this picture, we are searching for banana juice. We first type the keyword “banana” in the search field. The page was reloaded, and the results matching our search criteria rendered on the screen. The red arrows point to places where our keyword appears on the page. Let’s see this in terms of HTTP requests and responses. After typing our search keyword “banana,” an HTTP request is made to the server. Client issues a GET request, and our keyword is sent as a query string parameter queue.

When the server receives the request, it reads the query string parameter, runs a database query to retrieve records, matching our search criteria, and then computes the final HTML output to be rendered client side with all matching records. Then the server responds to the client, sending the final HTML to be rendered. Note that our keyword is also outputted as part of the HTML, and this is where troubles begin. What if, instead of searching for banana, we decide to search for an HTML tag? From the request point of view, everything remains the same. The server may not find any matching records in the database, but it still outputs our searching keywords next to search results title as highlighted with the red background.

When the browser receives the HTML to render, it doesn’t know that the highlighted part was provided as part of the request. It just knows that the server sends this HTML to be rendered. The HTML tag script has a special meaning, and the code inside the tag is executed in JavaScript, popping up the model box saying XSS. In this scenario, sharing the URL with other users will trigger the same behaviour in their browsers, meaning that we can run arbitrary code remotely. There are two main types of XSS. Server XSS is exactly what we have discussed until now. User supplied data, our search keyword, is included in an HTML response generated by the server.

In the described scenario, our search keyword does not start anywhere in the server. It is sent as part of the request and returned in the response. Due to this fact, it is called reflected server XSS. If it was stored somewhere, such as in a database, and later included in another response, such as a product review, then it would be called stored XSS. The other type is client XSS. In this case, untrusted data, such as a user supplied data, is used to update the DOM using an unsafe JavaScript call. Imagine that web application uses an API to perform product search. In this case, the server responds with a JSON object including the list of matching products.

When the API response arrives, the web application copies the content in the search input fields, appending it to the DOM next to the search results title, and then the list of matching products. In this scenario, the XSS payload was not part of server’s response. Instead, it was gathered from client side input field and appended to the DOM. There’s also reflected and stored client XSS, but you’re better reading about it in the OWASP website.