Cross-Site Scripting (XSS)
Lecture
What is Cross-Site Scripting?
Cross-Site scripting (XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the Same Origin Policy (SOP), which is designed to segregate different websites from each other. XSS normally allows an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.
Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.
Same-Origin Policy (SOP)
Same-Origin Policy (SOP) is a web browser security mechanism that aims to prevent websites from attacking each other. SOP restricts scripts on one origin from accessing data from another origin.
An origin consists of a URI scheme, domain and port number. For example, consider the following URL:
This uses the scheme http, the domain normal-website.com, and the port number 80. The following table shows how the same-origin policy will be applied if content at the above URL tries to access other origins:
| URL accessed | Access permitted? |
|---|---|
| Yes: same scheme, domain, and port |
| Yes: same scheme, domain, and port |
| No: different scheme and port |
| No: different domain |
| No: different domain |
| No: different port |
When a browser sends an HTTP request from one origin to another, any cookies, including authentication session cookies, relevant to the other domain are also sent as part of the request.
This means that the response will be generated within the user's session, and include any relevant data that is specific to the user. Without SOP, if you visited a malicious website, it would be able to read your emails from GMail, private messages from Facebook, etc.
XSS Types
There are three main types of XSS attacks. These are:
Reflected XSS, where the malicious script comes from the current HTTP request.
Stored XSS, where the malicious script comes from the website's database.
DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.
Reflected XSS
Reflected XSS arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way. Here is a simple example of a reflected XSS vulnerability:
The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:
If the user visits the URL constructed by the attacker, then the attacker's script executes in the user's browser, in the context of that user's session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.
Reflected XSSStored XSS
Stored XSS arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.
The data in question might be submitted to the application via HTTP requests. For example:
Comments on a blog post
User nicknames in a chat room
Contact details on a customer order
In other cases, the data might arrive from other untrusted sources. For example:
A webmail application displaying messages received over SMTP
A marketing application displaying social media posts
A network monitoring application displaying packet data from network traffic.
Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:
The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:
DOM-Based XSS
DOM-based XSS arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.
In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:
If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:
In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.
DOM-Based XSSXSS Contexts
XSS ContextsXSS Defense
Defense 1: HttpOnly
HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script (JavaScript) accessing the protected cookie. The example below shows the syntax used within the HTTP response header:
If the HttpOnly flag is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if XSS exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.
Defense 2: CSP
CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages.
To enable CSP, a response needs to include an HTTP response header called Content-Security-Policy with a value containing the policy. The policy itself consists of one or more directives, separated by semicolons.
Reference
Last updated
