Cross Site Scripting (XSS)

Cross Site Scripting (XSS)
Vulnerabilities, Attacks, and Mitigations

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Overview

The Nature of the Vulnerability:
- A "dynamic" (HTML) document that has user-supplied data written into it (as such, it can be considered an injection vulnerability)
The Nature of the Attack:
- The attacker "tricks" the user into supplying data to a server that ultimately causes harm (to the user, server, or third party)
The Trust Issue:
- The client inappropriately trusts the server (or, more accurately, the source)
Real-World Instances:
- See the Common Vulnerabilities and Exposures Glossary (CVE) or the National Vulnerabiltiies Database

Phases

Before the Attack:
- A page containing the vulnerability is added to the trusted server by a trusted party (e.g., the server administrator)
- The attacker creates malicious code and makes it the payload (e.g., the query string of an A element, the URL of a redirect, the contents of a FORM element) of a trigger document (e.g., an unsubscribe link in an email message) that references the page on the trusted server
During the Attack:
- The user receives the trigger document containing the malicious code
- The user (e.g., by clicking on a link) or user-agent (e.g., as a result of a redirect or script executing at load time) initiates an HTTP request containing the malicious code
- The "dynamic" document in the HTTP response includes the malicious code
- The malicious code is executed (either on the trusted server or the client) creating a modified document that appears to come from the trusted source
- The modified document is activated/used causing harm

Variants of the Vulnerability

Type 0/Local:
- The malicious code is executed on the user's device
Type 1/Reflected:
- The malicious code is executed on the trusted server
Type 2/Persistent:
- The malicious code is stored on the trusted server and subsequently executed on either the user's device (Type 2.0) or the server (Type 2.1)

Type 0/Local Vulnerabilities

The "Classic" Case - http:// Request to a Server

Type 0/Local Vulnerabilities (cont.)

The "Modern" (e.g., Desktop Widgets, Gadgets, Desklets) Case - file:// Request to the Local File System

Type 0/Local Vulnerabilities (cont.)

Potentially Vulnerable JavaScript:
- Any code that changes the Document (e.g., Document.write())
To Note:
- The code is executing on the client and has complete access to the document

A Type 0 Example

The Setting:
- The trusted party wants to a third party to "brand" a page (e.g., add a link back to the third party) using information in the query string
The Vulnerability:
- The data from the query string is used to modify the document using JavaScript
The Attack:
- The attacker creates a "dynamic" document apparently coming from the trusted source that can be used to trick users into providing credit card information

Type 1/Reflected Vulnerabilities

Type 1/Local Vulnerabilities (cont.)

Potentially Vulnerable PHP:
- echo, print/print(), printf()
- header()
- setcookie()
To Note:
- The code is executing on the server in the server's domain so can potentially attack any page at that domain (not just the page requested)

A Type 1 Example

The Setting:
- The trusted party wants to allow users to enter and preview formatted (in HTML) messages
The Vulnerability:
- The data from the FORM is written into a document using PHP
The Attack:
- The attacker creates a "dynamic" document apparently coming from the trusted source that can be used to trick users into providing email addresses of their friends

A Type 1 Example (cont.)

The Code on the Trusted Server

phpexamples/xss/trusted/create.html

<html>
  <body>
    <form action="preview.php" method="GET" name="feedback">
    Enter your message:<br/>
    <textarea name="message" rows="10" cols="80">
    </textarea><br/>
    <input type="submit" value="Preview" />
    </form>
  </body>
</html>

<html>
  <body>
    <p>
    A preview of your message:
    </p>

    <p style="border: 1px solid black">
    <script language="php">
    echo $_GET["message"];
    </script>
    </p>
  </body>
</html>

A Type 1 Example (cont.)

The Trigger Document Containing Malicious Code

phpexamples/xss/attacker/link-attack.html

<html>
  <body>
  <p>
  Click on the following link to send a quick email to a friend.
  </p>
  <a href="../trusted/preview.php?message=Call Me!%3C%2Fp%3E%3Cp%3E%3Cform%20action%3D'..%2Fattacker%2Freceive_secret.php'%20method%3D'POST'%3EEMAIL%20of%20Recipient%3A%20%3Cinput%20type%3D'email' %20name%3D'email'%20%2F%3E%3Cbr%2F%3E%3Cinput%20type%3D'submit'%20value%3D'Send'%20%2F%3E%3C%2Fform%3E">Send</a>
  </body>
</html>

Type 2/Persistent Vulnerabilities

On the Server:
- One or more pages that save user input (e.g., product reviews, comments)
- A page that reads the user input and writes it into a document (e.g., so that other users can see the reviews/comments)
During the Attack:
- The attacker provides the malicious code as user input
- The server saves the malicious code
- The user requests a page that includes the malicious code
- The malicious code is executed creating a modified document that appears to come from a trusted source
- The user activates a link in the modified document

Type 2/Persistent Vulnerabilities (cont.)

Pernicious Nature of the Attack:
- The user is using the site as intended (without the need for a malicious link)
Sub-Types:
- 2.0 - The malicious code is executed on the client
- 2.1 - The malicious code is executed on the server

Type 2/Persistent Vulnerabilities (cont.)

Payload of the Trigger Document

GET Request:
- Initiated by the user clicking on an A element
- Initiated by an http-refresh
- Initiated by a client-side scripting redirect (e.g., setting document.location in JavaScript)
- Initiated by a client-side event handler (e.g., in response to the document loading, in response to a mouse or keyboard event)
POST Request:
- Initiated by the user clicking on a SUBMIT element
- Initiated by a client-side event handler (e.g., a call to the Form object's submit() method in the Body object's onload handler)

Kinds of Malicious Code

Document Description/Presentation Code (sometimes called Content Spoofing):
- HTML Elements (e.g., A elements, FORM elements)
- CSS Styles
Executable Code:
- Client-side scripts (e.g., an onload handler written in JavaScript)
- Server-side scripts

The Location of the Code in the "Dynamic" Document

HTTP Header:
- Sometimes called response splitting
- Note that the Content-Length does not include the size of the header so the additions can't be detected easily
- Only possible for Type 1 and Type 2.1 vulnerabilities
Document Head:
- Changing/adding META elements
- Changing/adding client-side scripts
Document Body:
- Additions to the trusted document (e.g., additional fields in a FORM element)
- Executable code that modifies the trusted document (e.g., changing the href of A elements)

Obviousness of the Malicious Code in User-Initiated GET Requests

Recall:
- When the vulnerability arises from the processing of a GET request the malicious code is included in the query string
A Misconception:
- Users will notice the query string
Why this is a Misconception:
- Users don't notice
- Not all user agents display the query string (e.g., browsers on small devices may not have a "hover" event)
- The URL can be disguised
Methods of Disguise:
- Redirection (of various kinds)
- URL Shortening Services
- Use of homographs (a character in one alphabet that look like a character in another alphabet)

Mitigation During Design

Use an Alternative Markup Language:
- XSS vulnerabilities often arise when users are allowed to enter HTML so, instead, have them use a different markup language
Eliminate User Data in "Dynamic" Documents:
- Possible in some applications but not others

Mitigation During Implementation

Encode/Escape Data:
- HTML encoding (e.g., using htmlentities() in PHP) of data written into "dynamic" documents (e.g., <p> becomes <p>)
- URL encoding (e.g., using encode() in JavaScript) of data written into URLs (e.g., a space becomes %20)
Validate/Sanitize Input:
- Remove potentially malicious data (e.g., using regular expressions or libraries like HTMLPurifier for PHP)
- Allow-listing is preferred to deny-listing
Use HttpOnly Cookies:
- To hide cookies from scripts

Mitigation During Validation/Verification

Code Reviews:
- Look for the potentially vulnerable statements/functions
Testing:
- Make requests in which all possible input values contain malicious code and review the raw HTML (e.g., using tools like AppScan, libwhisker, or WebScarab)

Mitigation During Deployment

Content Security Policy (CSP):
- A Candidate Recommendation of the W3C that allows for the specification of approved sources of content
NoScript:
- An extension for some browsers that allows executable content only from allowlisted sources