XSS Tutorial

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications, such as web browsers through breaches of browser security, that enables attackers toinject client-side script 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 80.5% of all security vulnerabilities documented by Symantec as of 2007.^[1] Their effect 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 mitigation implemented by the site's owner.

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 web 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 ofJavaScript 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, and SQL Queries), causing some confusion to newcomers to the field of information security.^[2]

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter,^[3] Facebook,^[4] MySpace, and Orkut.^[5][6] In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly reported security vulnerability,^[7] with some researchers in 2007 viewing as many as 68% of websites as likely open to XSS attacks.^[8]

XSS attacks are also dangerous in post-auth zones and can be exploited on web pages that requires user authentication to access. Such vulnerabilities are also called "post-authentication XSS". White Paper entitled "Practical exploitation of post-authentication vulnerabilities in web applications" demonstrates several practical examples of exploitation of XSS vulnerabilities on web pages that requires administrator's credentials to access.^[9]

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 

-persistent. 

-Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type.^[11] 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.^[12]

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.^[11][12] 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.^[13]

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.

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.

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 (either directly or through an iframe or ajax), 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

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.^[12]

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, a hacker, joins the site and wants to figure out the real names of the men she sees on the site. To do so, she writes a script that runs from men's browsers when they visither 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 (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.

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.^[15]

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 filesystem contents via a QuickTime movie on MySpace.

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.

DOM-Based : The DOM-Based Cross-Site Scripting allow to an attacker to work not on a victim website but on a victim local machine: the various operative system usually includes "since born" some HTML pages created for differents aims, but as long as the humans do mistakes this HTML pages often can be exploited due to code vulnerabilities.

The DOM-Based XSS exploits these problems on users local machines in this way:

 - The attacker creates a well builded malicious website

 - The ingenuous user opens that site

 - The user has a vulnerable page on his machine

 - The attacker's website sends commands to the vulnerable HTML page

 - The vulnerable local page execute that commands with the user's privileges

  on that machine.

 - The attacker easily gain control on the victim computer

Framework:

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