An attacker has many attack vectors to inject a payload into the target application. The first way is by manipulating the URI to inject code into request parameters, which are processed by a client-side script of the target application. Whenever the client-side script constructs code using these parameters, which it does not expect to hold code, the attacker’s code will be executed alongside the legitimate application code. This type of XSS attack is known as DOM-based XSS or XSS type 0.
The second class of XSS attacks consists of tricking the server into including the attacker’s code in its response. For example, if the attacker makes the victim’s browser visit the URI shown in Figure 2.8, the server will reflect the value of the URI parameter back in the response, where it will be executed as part of the requested page. This type is known as reflected XSS or XSS type. Finally, an attacker can also store the malicious code in the application’s data, for example by hiding it in a forum post or blog comment. Whenever the victim requests a page that includes the attacker’s content, the malicious code will be embedded in the page as well. This type of XSS is known as stored XSS or XSS type 2.
In essence, the problem of an XSS attack is the failure of the target application to recognize the insertion of code, thus allowing the payload to be executed. The combination of the facts that code can be placed anywhere in a document, and that browsers attempt to correct syntactically incorrect documents rather than rejecting or ignoring them helps the easy exploitation of injection vulnerabilities.
Injection vulnerabilities leading to XSS attacks are prevalent in both new and legacy Web applications. A large-scale analysis of the Alexa top 5,000 sites has discovered 6,167 unique XSS vulnerabilities, distributed over 480 domains. Cross-site scripting attacks are often only the first step in a more complicated attack, involving underlying infrastructure or higher-privilege accounts. The consequences of escalating an XSS attack are aptly demonstrated by exploitation frameworks, such as the Browser Exploitation Framework (BeEF) or Metasploit. Currently, almost every newly developed Web application sanitizes its inputs and outputs, in an attempt to avoid injection vulnerabilities altogether. Most modern development frameworks offer library support for sanitization.
Unfortunately, sanitization libraries are not always context-sensitive, and many applications apply sanitization procedures wrongly or inconsistently. Additionally, a few context-sensitive sanitization libraries are available, as discussed above as an aspect of mitigation techniques. Since injection vulnerabilities remain widespread, several attempts have been made to stop them from within the browser, independent of any application-specific mitigation techniques. Examples of in-browser mitigation techniques are XSS filters, or the popular security add-on NoScript. The newly introduced Content Security Policy (CSP) is slowly starting to be adopted. July 2014 survey of the Alexa top 10,000 sites found 131 sites that already issue a CSP policy in their response headers.
Additionally, applications often apply code-based isolation techniques to prevent the damage that can be done by untrusted or injected scripts. Examples of currently available isolation techniques are HTML 5 sandboxes, or browser-based sanitization procedures for dynamic script code, such as Internet Explorer to StaticHTML().