Cross-site scripting (XSS)

The Internet uses several types of content like text, audio, video, and multi-media. Textual content is usually static unless animated on purpose, while multi-media is dynamic. Websites displaying dynamic content are more prone to a threat known as cross-site scripting (XSS). In the abbreviation, ‘X’ apparently appears to be an error; however, in order not to confuse with the abbreviation CSS (Cascading Style Sheet), the abbreviation XSS is used to designate cross-site scripting. Some justify it as X (Cross) S (Site) S (Scripting).

XSS vulnerability is a flaw/hole in web applications. Attackers target such flaws/holes to send malicious code. XSS enables attackers to inject 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. 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.

THREATS POSED BY XSS
Scammers, spammers, hackers, phishers, malware authors and all other types of cybercriminals need sensitive data to execute their nefarious activities. By using XSS attacks, they aim to procure such sensitive data. They accomplish this by injecting malicious code in the form of JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to deceive an unsuspecting user. Once the data is gathered, it may be used for various online crimes including cookie theft/poisoning, false advertising, changing user settings, account hijacking, spoofing, etc. If financial data is gathered than financial crimes may be perpetrated. The data may also be used for sucker lists to be traded among cybercriminals.

CLASSIFYING XSS
A standard classification has not yet evolved, however, experts agree on classifications like non-persistent (or reflected) and persistent (or stored). Some further divide these into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

1. Non-persistent (or reflected). This is the most common cross-site scripting vulnerability. 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.

For example:
– A, a user, often visits a particular website, which is hosted by Z, a host. Z’s website allows A to log in with a username/password pair and stores sensitive data, such as billing information.
– H, a hacker, observes that Z’s website contains a reflected XSS vulnerability.
– H crafts a URL to exploit the vulnerability, and sends A an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Z’s website (either directly or through an iframe or ajax), but will contain H’s malicious code, which the website will reflect.
– A visits the URL provided by H while logged into Z’s website.
– The malicious script embedded in the URL executes in A’s browser, as if it came directly from Z’s server (this is the actual XSS vulnerability). The script can be used to send A’s session cookie to H. H can then use the session cookie to steal sensitive information available to A (authentication credentials, billing info, etc.) without A’s knowledge.

2. Persistent (or stored). This 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. 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 may be further designed to self-propagate across accounts, creating a type of a client-side worm.

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 H, a hacker, joins the site and wants to figure out the real names of the people on the site. To do so, H writes a script designed to run from other people’s browsers when they visit H’s profile. The script then sends a quick message to H’s own server, which collects this information.
– To do this, suppose for the question “Describe your Ideal First Date”, H gives a short answer (to appear normal) but the text at the end of H’s answer is H’s script to steal names and emails. If the script is enclosed inside a <script> element, it won’t be shown on the screen.
– Now suppose that A, a member of the dating site, views H’s profile. H’s profile has H’s answer to the First Date question, which also has the malicious script of H unseen by A. While A is viewing the profile of H, H’s malicious script is run automatically by A’s browser. The malicious script gathers all the information of A’s computer including A’s real name, email, password, etc., directly from A’s own machine, and sends a quick message to H’s own server where the information is collected.
– Now, by using A’s real name, email, and password, H can impersonate A on that site. Further, according to the sensitivity of the data gathered from A’ s computer, H can decide which crime(s) to commit.

Traditional cross-site scripting vulnerabilities occur in server-side code responsible for preparing the HTML response to be served to the user. DOM-based vulnerabilities occur in the content processing stages performed by the client, typically in client-side JavaScript.

REDUCING THE XSS THREAT
– Contextual output encoding/escaping of string input. 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.

– 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 (say, <b>very</b> good), output encoding (such as &lt;b&gt;very&lt;/b&gt; good) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows “very” as bold, instead of “<b>very</b>”). 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 it does not contain XSS. HTML sanitization tools may be used.

– Cookie security. 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 as the victim, or the victim is changing his or her mobile IP.

– Disabling scripts. 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.

– Changing passwords frequently. By frequent changing of passwords, the effect of being victimized by XSS attacks is reduced.

– Not clicking on embedded links. Many sites have links pointing to outside websites. Such links may contain hidden malicious XSS scripts that get activated once you click on the link. Instead of clicking on the links, you may visit the home page of the link directly and then use the search feature to find the relevant content. For example, if there is a link to SomeOutsideSite in a website, which seems interesting. Instead of clicking on the link given, it is better to visit SomeOutsideSite directly by typing the URL in the browser address bar. Thereafter the search feature given in SomeOutsideSite may be used to search the content that seemed interesting.

Technologies are emerging to fight the XSS threats. The three classes of XSS defense that are emerging include, Mozilla’s Content Security Policy, Javascript Sandbox tools, and Auto-escaping templates. With these technologies, it is hoped that the threats posed by XSS will be heavily reduced.

Brian Contos, CISSP, Chief Security Strategist for Imperva, explains Cross Site Scripting in the following YouTube video:

REFERENCES:
1. “Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)” (PDF) XIII. Symantec Corp. April 2008. pp. 1–3. http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf
2. Grossman, Jeremiah (July 30, 2006). “The origins of Cross-Site Scripting (XSS)“. http://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html
3. Arthur, Charles (September 21, 2010). “Twitter users including Sarah Brown hit by malicious hacker attack“. The Guardian. http://www.guardian.co.uk/technology/blog/2010/sep/21/twitter-bug-malicious-exploit-xss
4. Leyden, John (May 23, 2008). “Facebook poked by XSS flaw“. The Register. http://www.theregister.co.uk/2008/05/23/facebook_xss_flaw/
5. “Cross-site Scripting“. Web Application Security Consortium. 2005. http://projects.webappsec.org/Cross-Site-Scripting
6. Grossman, Jeremiah and Robert Hansen, Seth Fogie, Petko D. Petkov and Anton Rager (2007). “XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract)“. Elsevier Science & Technology via Google Book Search. pp. 70, 156. ISBN 1-59749-154-3. http://books.google.com/?id=dPhqDe0WHZ8C