Cross-site scripting

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications
that enables malicious attackers to inject client-side script into web pages viewed by other users. An
exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the
same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security
vulnerabilities documented by Symantec as of 2007.Their impact may range from a petty nuisance to a
significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the
nature of any security mitigations implemented by the site's owner.

(1) Background

Cross-site scripting holes are web application vulnerabilities that allow attackers to bypass client-
side security mechanisms normally imposed on web content by modern browsers. By finding
ways of injecting malicious scripts into web pages, an attacker can gain elevated access
privileges to sensitive page content, session cookies, and a variety of other information
maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a
special case of code injection.

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 (a reflected or
non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes
of code injection, including persistent and non-JavaScript vectors (including Java, ActiveX,
VBScript, Flash, or even pure HTML), causing some confusion to newcomers to the field of
information security.

XSS vulnerabilities have been reported and exploited since the 1990s. Some prominent sites that
have been affected in the past are the social networking sites Twitter, Facebook, MySpace, and
Orkut. The developers of Media Wiki have fixed at least 26 XSS holes in order to protect
Wikipedia and other wiki users. In recent years, cross-site scripting flaws surpassed buffer
overflows to become the most common publicly-reported security vulnerability, with some
researchers claiming that as many as 68% of websites are likely open to XSS attacks.

(2) Types
There is no single, standardized classification of cross-site scripting flaws, but most experts
distinguish between at least two primary flavors of XSS: non-persistent and persistent. Some
sources further divide these two groups into traditional (caused by server-side code flaws) and
DOM-based (in client-side code).
2.1) Non-persistent

The non-persistent (or reflected) cross-site scripting vulnerability is by far the

most common type.[ These holes show up when the data provided by a web client, most
commonly in HTTP query parameters or in HTML form submissions, is used
immediately by server-side scripts to generate a page of results for that user, without
properly sanitizing the request.

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.

At first blush, this does not appear to be a serious problem: by submitting a malicious
input to the web site, the user would only be able to compromise their own security
context—that is, their own browser cookies, cache objects, and so forth. It is important to
realize, however, that a third-party attacker may easily place hidden frames or deceptive
links on unrelated sites and cause victims' browsers to navigate to URLs on the
vulnerable site automatically—often completely in the background—and in such a case,
the attacker can intrude into the security context that rightfully belonged to the victim.

Example of non-persistent XSS

Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack

Google users who visit them while logged in.

2.2) Persistent

The persistent (or stored) 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.

Persistent XSS can be more significant than other types because an attacker's malicious
script is rendered automatically, without the need to individually target victims or lure
them to a third-party website. Particularly in the case of social networking sites, the code
would be further designed to self-propagate across accounts, creating a type of a client-
side worm.

The methods of injection can vary a great deal; in some cases, the attacker may not even
need to directly interact with the web functionality itself to exploit such a hole. Any data
 received by the web application (via email, system logs, etc.) that can be controlled by an
attacker could become an injection vector.

Example of persistent XSS

A persistent cross-zone scripting vulnerability coupled with a computer worm

allowed execution of arbitrary code and listing of file system contents via a
QuickTime movie on MySpace.

2.3) Traditional versus DOM-based vulnerabilities

Traditionally cross-site scripting vulnerabilities would occur in server-side code

responsible for preparing the HTML response to be served to the user. With the advent of
web 2.0 applications a new class of XSS flaws emerged, DOM-based vulnerabilities.
DOM-based vulnerabilities occur in the content processing stages performed by the
client, typically in client-side JavaScript. The name refers to the standard model for
representing HTML or XML contents which is called the Document Object Model
(DOM). JavaScript programs manipulate the state of a web page and populate it with
dynamically-computed data primarily by acting upon the DOM.

A typical example is a piece of JavaScript accessing and extracting data from the URL
via the location.* DOM, or receiving raw non-HTML data from the server via
XMLHttpRequest, and then using this information to write dynamic HTML without
proper escaping, entirely on client side.

Example of DOM-based XSS

Before the bug was resolved, Bugzilla error pages were open to DOM-based XSS
attack in which arbitrary HTML and scripts could be injected using forced error
messages.

(3) Exploit scenarios

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of
vulnerability differently. For each class, a specific attack vector is described here. The names
below are technical terms, taken from the cast of characters commonly used in computer
security.

Non-persistent:

1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows
Alice to log in with a username/password pair and stores sensitive data, such as billing
information.
2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
 3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her
to click on a link for the URL under false pretenses. This URL will point to Bob's
website, but will contain Mallory's malicious code, which the website will reflect.
4. Alice visits the URL provided by Mallory while logged into Bob's website.
5. The malicious script embedded in the URL executes in Alice's browser, as if it came
directly from Bob's server (this is the actual XSS vulnerability). The script can be used to
send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal
sensitive information available to Alice (authentication credentials, billing info, etc.)
without Alice's knowledge.

Persistent attack:

1. Mallory posts a message with malicious payload to a social network.

2. When Bob reads the message, Mallory's XSS steals Bob's cookie.
3. Mallory can now hijack Bob's session and impersonate Bob.

Framework:

A Browser Exploitation Framework could be used to attack the web site and the user's local
environment.

(4)Mitigation

4.1) Contextual Output Encoding/Escaping of String Input

The primary defense mechanism to stop XSS is contextual output encoding/escaping.

There are several different escaping schemes that must 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 (or percent) encoding. Most web
applications that do not need to accept rich data can use escaping to largely eliminate the
risk of XSS in a fairly straightforward manner.

It is worth noting that although it is widely recommended, simply performing HTML

entity encoding on the five XML significant characters is not always sufficient to prevent
many forms of XSS. Encoding can be tricky, and the use of a security encoding library is
highly recommended.
4.2) Safely Validating Untrusted HTML Input

Many operators of particular web applications (e.g. forums and webmail) wish to allow users to
utilize some of the features HTML provides, such as 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 XSS when accepting HTML input from users is
much more complex in this situation. Untrusted HTML input must be run through an HTML
policy engine to ensure that is does not contain XSS. Tools such as OWASP AntiSamy and
http://htmlpurifier.org/ accomplish this task.

4.3) Cookie security

Besides content filtering, other imperfect methods for cross-site scripting mitigation are
also commonly used. One example is the use of additional security controls when
handling cookie-based user authentication. Many web applications rely on session
cookies for authentication between individual HTTP requests, and because client-side
scripts generally have access to these cookies, simple XSS exploits can steal these
cookies. To mitigate this particular threat (though not the XSS problem in general), many
web applications tie session cookies to the IP address of the user who originally logged
in, and only permit that IP to use that cookie. This is effective in most situations (if an
attacker is only after the cookie), but obviously breaks down in situations where an
attacker is behind the same NATed IP address or web proxy—or simply opts to tamper
with the site or steal data through the injected script, instead of attempting to hijack the
cookie for future use.

Another mitigation present in IE (since version 6), Firefox (since version 2.0.0.5), Safari
(since version 4) and Google Chrome, is a HttpOnly flag which allows a web server to set
a cookie that is unavailable to client-side scripts. While beneficial, the feature does not
fully prevent cookie theft nor can it prevent attacks within the browser.
4.4) Disabling scripts

Finally, while Web 2.0 and Ajax designers favor the use of JavaScript, some web
applications are written to (sometimes optionally) operate completely without the need
for client-side scripts. This allows users, if they choose, to disable scripting in their
browsers before using the application. In this way, even potentially malicious client-side
scripts could be inserted unescaped on a page, and users would not be susceptible to XSS
attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a

per-domain basis. If scripting is allowed by default, then this approach is of limited value,
since it blocks bad sites only after the user knows that they are bad, which is too late.
Functionality that blocks all scripting and external inclusions by default and then allows
the user to enable it on a per-domain basis is more effective. This has been possible for a
long time in IE (since version 4) by setting up its so called "Security Zones", and in
Opera (since version 9) using its "Site Specific Preferences". A solution for Firefox and
other Gecko-based browsers is the open source NoScript add-on which, in addition to the
ability to enable scripts on a per-domain basis, provides some anti-XSS protection even
when scripts are enabled.

The most significant problem with blocking all scripts on all websites by default is
substantial reduction in functionality and responsiveness (client-side scripting can be
much faster than server-side scripting because it does not need to connect to a remote
server and the page or frame does not need to be reloaded). Another problem with script
blocking is that many users do not understand it, and do not know how to properly secure
their browsers. Yet another drawback is that many sites do not work without client-side
scripting, forcing users to disable protection for that site and opening their systems to
vulnerabilities. The Firefox NoScript extension enables users to allow scripts selectively
from a given page while disallowing others on the same page. For example, scripts from
example.com could be allowed, while scripts from advertisingagency.com that are
attempting to run on the same page could be disallowed.
 4.5) Emerging defensive technologies

There are three classes XSS of defense that are emerging. These include, Mozilla's Content
Security Policy https://wiki.mozilla.org/Security/CSP/Specification, Javascript Sandbox tools, and
Auto-escaping templates. These mechanisms are still evolving but promise a future of heavily
reduced XSS.

(5) Scanning service

Some companies offer a periodic scan service, essentially simulating an attack from their server to a
client's in order to check if the attack is successful. If the attack succeeds, the client receives detailed
information on how it was performed and thus has a chance to fix the issues before the same attack is
attempted by someone else. A trust seal can be displayed on the site that passes a recent scan. The
scanner may not find all possible vulnerabilities, and therefore sites with trust seals may still be
vulnerable to new types of attack, but the scan may detect some problems. After the client fixes them,
the site is more secure than it was before using the service. For sites that require complete mitigation of
XSS, assessment techniques like manual code review are necessary.

(6) Related vulnerabilities

Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting
exploits "zone" concepts in certain browsers and usually executes code with a greater privilege.
HTTP header injection can be used to create cross-site scripting conditions due to escaping
problems on HTTP protocol level (in addition to enabling attacks such as HTTP response
splitting).
Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than
exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in
the client software, submitting requests that the site believes represent conscious and intentional
actions of authenticated users.

Lastly, SQL injection exploits a vulnerability in the database layer of an application. When user
input is incorrectly filtered any SQL statements can be executed by the application.