Cross-site Scripting (XSS) is a much talked-about type of injection vulnerability that occurs on the client-side (that is, in a user’s browser). It occurs, predominantly through the use of JavaScript due to its prevalence in most browsing experiences.
Cross-site Scripting can be classified into four major categories – Stored XSS, Reflected XSS, DOM-based XSS and Blind XSS. In all cases with XSS, the goal of an attacker is to get a victim to inadvertently execute a maliciously injected script. The malicious script is often referred to as a malicious payload, or simply a payload.
Stored (Persistent) XSS attacks involve an attacker injecting a script (referred to as the payload) that is permanently stored (persisted) on the target application (for instance within a database, in a comment field or in a forum post).
Reflected XSS attacks involve an attacker in luring in a victim to inadvertently make an HTTP request containing an XSS payload to a web server, usually achieved through phishing or other social engineering attacks. Once sent to the web server, the payload is then reflected back in such a way that the HTTP response includes the payload from the HTTP request.
DOM-based XSS is an advanced type of XSS wherein a payload is executed as a result of legitimate client-side JavaScript modifying the Document Object Model (DOM) in a victim’s browser. In contrast to the other types of XSS, with DOM-based XSS, the HTTP response itself does not typically change, but rather client side code designed to process elements in the DOM, executes the malicious payload that has been injected in the DOM elements processed by the vulnerable JavaScript code.
When a web application is vulnerable to XSS, it will load the attacker-supplied content from a source that the application implicitly trusts, without properly encoding it.
With stored and blind XSS, implicitly-trusted data is loaded from a datastore (such as a database or cache); with reflected XSS, the implicitly-trusted data is loaded from the HTTP request; and with a DOM-based XSS, implicitly-trusted data is loaded from a DOM-XSS source within the browser’s DOM.
In every case, XSS would result in the browser interpreting the attacker’s payload as legitimate JavaScript code, and subsequently executing it. It is important to note that an XSS vulnerability can only exist if the attacker’s payload ultimately gets rendered in the victim’s browser.
The consequences of an XSS attack may not be immediately obvious, especially since modern web browsers run JavaScript in a tightly controlled environment and since JavaScript has limited access to the user’s operating system and the user’s files.
However, when considering that malicious JavaScript has access to all the same objects as the rest of the web page, including access to cookies which are often used to store session tokens, if an attacker can obtain a user’s session cookie, they can then impersonate that user.
Furthermore, JavaScript can read and make arbitrary modifications to the browser’s DOM (within the page in which that script is running).
JavaScript can also be leveraged to send HTTP requests with arbitrary content to arbitrary destinations, and in modern browsers, can leverage HTML5 APIs such as accessing a user’s geolocation, webcam, microphone and even the specific files from the victim’s file system. While such APIs require the victim’s opt-in, XSS in conjunction with some clever social engineering can bring an attacker a long way.
The above reasons should hopefully dispel any doubts that XSS is a serious vulnerability, but what about its prevalence? JavaScript’s use on the web has been growing at a mind-boggling pace in the past few years. In our latest Web Application Vulnerability Report we registered a 5% drop in XSS from the previous year.
While that is good news, the fact that XSS at 33% of sampled targets being vulnerable to XSS, there is clearly still a lot of wiggle room for attackers to abuse XSS.
This post contained excerpts from the 2016 Acunetix Web Application Vulnerability Report. For more stats and coverage on web application vulnerabilities in 2016, download the report for free.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
