Content deleted Content added
→Background: Briefly illustrate "URI Scheme" (this is definitely jargon that needs it) |
|||
| (102 intermediate revisions by 62 users not shown) | |||
Line 1:
{{Short description|Security issue for web applications}}{{Use mdy dates|date=June 2019}}{{Redirect|XSS}}
'''Cross-site scripting''' ('''XSS'''){{Efn|The abbreviation 'XSS' is commonly used to avoid confusion with [[cascading style sheets]].}} is a type of security [[vulnerability (computer science)|vulnerability]] that can be found in some [[web application]]s. XSS attacks enable attackers to [[code injection|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]]. 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 [[Computer network|network]].
[[OWASP]] considers the term cross-site scripting to be a [[misnomer]]. It initially was an attack that was used for breaching data across sites, but gradually started to include other forms of data injection attacks.<ref>{{Cite web |title=Cross Site Scripting Prevention - OWASP Cheat SheetSeries|url=https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html |access-date=2003-03-19 |website=[[OWASP]]}}</ref>
==Background==
{{Main|Web security|Same-origin policy}}
Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the [[same-origin policy]]. This states that if content from one site (such as ''<nowiki>https://mybank.example1.com</nowiki>'') is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) [[URI scheme]] (e.g. ftp, http, or https), (2) [[host name]], ''and'' (3) [[port number]] will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.<ref>{{cite web |title= Same Origin Policy - Web Security. W3.org. |url= http://www.w3.org/Security/wiki/Same_Origin_Policy |access-date= November 4, 2014 }}</ref>
Cross-site scripting attacks use known vulnerabilities in [[Web application|web-based applications]], their [[Server (computing)|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.<ref name="xssname">{{cite web |author= "dross" on MSDN |title= Happy 10th birthday Cross-Site Scripting! |url= https://learn.microsoft.com/en-ca/archive/blogs/dross/happy-10th-birthday-cross-site-scripting |date=15 Dec 2009 |access-date= 2023-02-09| quote = On the 16th of January, 2000, the following names were suggested and bounced around among a small group of Microsoft security engineers: [...] The next day there was consensus – Cross Site Scripting. }}</ref>{{Non-primary source needed|date=October 2024}} 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 [[same-origin policy|security context]] of the targeted ___domain (taking advantage of 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 [[ActiveX]], [[Java (programming language)|Java]], [[VBScript]], [[Adobe Flash|Flash]], or even [[HTML]] scripts), causing some confusion to newcomers to the field of [[information security]].<ref name="Grossman">{{cite web |last= Grossman |first= Jeremiah |title= The origins of Cross-Site Scripting (XSS) |url= http://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html |date= July 30, 2006 |access-date= September 15, 2008 }}</ref>
XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites [[Twitter]]<ref>{{cite news |last= Arthur |first= Charles |title= Twitter users including Sarah Brown hit by malicious hacker attack |url= https://www.theguardian.com/technology/blog/2010/sep/21/twitter-bug-malicious-exploit-xss |date= September 21, 2010 |newspaper= The Guardian |access-date= September 21, 2010 }}</ref> and
Line 29 ⟶ 28:
===Non-persistent (reflected)===
The ''non-persistent'' (or ''reflected'') cross-site scripting vulnerability is by far the most basic type of web vulnerability.<ref name="HopeWalther">{{Cite book |last1=Paco |first1=Hope |last2=Walther |first2=Ben |title=Web Security Testing Cookbook |publisher=O'Reilly Media, Inc. |year=2008 |___location=Sebastopol, CA |page=[https://archive.org/details/websecuritytesti00hope/page/128 128] |isbn=978-0-596-51483-9 |url-access=registration |url=https://archive.org/details/websecuritytesti00hope/page/128 }}</ref> These holes show up when the data provided by a web client,<ref>{{Cite journal |last1=Hydara |first1=Isatou |last2=Sultan |first2=Abu Bakar Md. |last3=Zulzalil |first3=Hazura |last4=Admodisastro |first4=Novia |date=2015-02-01 |title=Current state of research on cross-site scripting (XSS) – A systematic literature review |url=https://linkinghub.elsevier.com/retrieve/pii/S0950584914001700 |journal=Information and Software Technology |language=en |volume=58 |pages=170–186 |doi=10.1016/j.infsof.2014.07.010|url-access=subscription }}</ref> most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly [[HTML sanitization|sanitizing]] the content.<ref name="WASC-2005">{{cite web |title=Cross-site Scripting |url=http://projects.webappsec.org/Cross-Site-Scripting |year=2005 |publisher=Web Application Security Consortium |access-date=May 28, 2008}}</ref>
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.<ref name="HopeWalther" /><ref name="WASC-2005" /> 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 character|escape]] or reject HTML control characters, a cross-site scripting flaw will ensue.<ref name="GHFPR">{{cite book |last1=Grossman |first1=Jeremiah |first2=Robert |last2=Hansen |first3=Seth |last3=Fogie |first4=Petko D. |last4=Petkov |first5=Anton |last5=Rager |title=XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract) |pages=70, 156 |url=https://books.google.com/books?id=dPhqDe0WHZ8C |year=2007 |publisher=Syngress |isbn=978-1-59749-154-9 |access-date=May 28, 2008}}</ref>
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'' (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.<ref name="WASC-2005" />
Line 61 ⟶ 48:
===Server-side versus DOM-based vulnerabilities===
XSS vulnerabilities were originally found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in [[JavaScript]]) working on the client-side that pulled data, on-demand, from the server using [[AJAX]].
Line 73 ⟶ 55:
===Self-XSS===
{{Main|Self-XSS}}
[[Self-XSS]] is a form of XSS vulnerability that relies on [[Social engineering (security)|social engineering]] in order to trick the victim into executing malicious JavaScript code in their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed.<ref>{{cite web |title= Self-XSS Facebook scam attempts to trick users into hacking themselves |work= www.majorgeeks.com |date= 2014-07-29 |url= http://www.majorgeeks.com/news/story/self_xss_facebook_scam_attempts_to_trick_users_into_hacking_themselves.html |access-date= 2016-09-20 }}</ref>
===Mutated XSS (mXSS) ===
Mutated XSS happens when the attacker injects something that is seemingly safe but is rewritten and modified by the browser while parsing the markup. This makes it extremely hard to detect or sanitize within the website's application logic. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.
== Preventive measures ==
===Contextual output encoding/escaping of string input===
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 [[Percent-encoding|URL (or percent) encoding]].<ref name="OWASP">{{cite web |last=Williams |first=Jeff |title=XSS (Cross Site Scripting) Prevention Cheat Sheet |url=https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet |publisher=OWASP |date=January 19, 2009 |access-date=February 4, 2010 |archive-date=March 18, 2017 |archive-url=https://web.archive.org/web/20170318125710/https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet |url-status=dead }}</ref> 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.
Performing HTML entity encoding only on the [[List of XML and HTML character entity references#Standard_public_entity_sets_for_characters|five XML significant characters]] is not always sufficient to prevent many forms of XSS attacks, security encoding libraries are usually easier to use.<ref name="OWASP" />
Some [[web template system]]s understand the structure of the HTML they produce and automatically pick an appropriate encoder.<ref>{{Cite web|url=https://golang.org/pkg/html/template/#hdr-Introduction|title=template - The Go Programming Language|website=golang.org|access-date=2019-05-01}}</ref><ref>{{Cite web|url=https://www.npmjs.com/package/pug-plugin-trusted-types|title=pug-plugin-trusted-types|website=npm|access-date=2019-05-01}}</ref>
===Safely validating untrusted HTML input ===
Many operators of particular web applications (e.g. forums and webmail) allow users to utilize HTML markup. When accepting HTML input from users (say, <code><b>very</b> large</code>), output encoding (such as <code>&lt;b&gt;very&lt;/b&gt; large</code>) 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. Often, untrusted HTML input must be run through an [[HTML sanitization]] engine to ensure that it does not contain XSS code.
For example, if a user enters
<syntaxhighlight lang="html">
<span style="color: blue;">Hello world</span>
<script>alert("XSS")</script>
</syntaxhighlight>
then the application processing the markup may allow the <code><<nowiki />span></code> but escape the <code><script></code> tag when the input is displayed:
<syntaxhighlight lang="html">
<span style="color: blue;">Hello world</span>
<script>alert("XSS")</script>
</syntaxhighlight>
Many validations rely on parsing out (blacklisting) specific "at risk" HTML tags such as the [[IFRAME|<code><<nowiki />iframe></code>]], <code><<nowiki />link></code>, and <code><script></code> tag, or by only allowing certain tags and removing or escaping others.
There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS
Another popular method is to strip user input of " and ' however this can also be bypassed as the payload can be concealed with [[obfuscation]].
===Cookie security===
{{Further information|HTTP cookie}}
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 [[HTTP cookie|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.<ref name="Sharma">{{cite web |last=Sharma |first=Anand |title=Prevent a cross-site scripting attack |url=http://www.ibm.com/developerworks/ibm/library/wa-secxss/ |publisher=IBM |date=February 3, 2004 |access-date=May 29, 2008 }}</ref> 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.<ref name="ModSecurity">{{cite web |title=ModSecurity: Features: PDF Universal XSS Protection |url=http://www.modsecurity.org/projects/modsecurity/apache/feature_universal_pdf_xss.html |archive-url=https://web.archive.org/web/20080323040609/http://www.modsecurity.org/projects/modsecurity/apache/feature_universal_pdf_xss.html |url-status=dead |archive-date=March 23, 2008 |publisher=Breach Security |access-date=June 6, 2008 }}</ref> 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 [[Network address translation|NAT]]ed IP address or [[web proxy]] as the victim, or the victim is changing his or her [[mobile IP]].<ref name="ModSecurity" />
====Http-only cookie====
{{Main|Http-only cookie}}
Another mitigation present in [[Internet Explorer]] (since version 6), [[Firefox]] (since version 2.0.0.5), [[Safari (web browser)|Safari]] (since version 4), [[Opera (web browser)|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.<ref>{{cite web |title=Ajax and Mashup Security |url=http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.php |publisher=OpenAjax Alliance |access-date=June 9, 2008 |url-status=dead |archive-url=https://web.archive.org/web/20080403234132/http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.php |archive-date=April 3, 2008 |df=mdy-all }}</ref>
Line 161 ⟶ 113:
=== Selectively disabling scripts ===
====Content Security Policy====
{{Main|Content Security Policy}}
[[Content Security Policy]] (CSP) allows HTML documents to opt in to disabling some scripts while leaving others enabled.<ref>{{Cite web|url=https://www.w3.org/TR/CSP3/Overview.html|title=Content Security Policy Level 3|website=www.w3.org|access-date=2019-05-01}}</ref> The browser checks each script against a policy before deciding whether to run it. As long as the policy only allows trustworthy scripts and disallows [[Eval|dynamic code loading]], the browser will not run programs from untrusted authors regardless of the HTML document's structure.
Modern CSP policies allow using [[Cryptographic nonce|nonces]] to mark scripts in the HTML document as safe to run instead of keeping the policy entirely separate from the page content.<ref>{{Cite web|url=https://caniuse.com/#feat=contentsecuritypolicy2|title=Can I use... Support tables for HTML5, CSS3, etc|website=caniuse.com|access-date=2019-05-01}}</ref><ref>{{Cite web|url=https://csp.withgoogle.com/docs/strict-csp.html|title=Strict CSP - Content Security Policy|website=csp.withgoogle.com|access-date=2019-05-01}}</ref> As long as trusted nonces only appear on trustworthy scripts, the browser will not run programs from untrusted authors. Some large application providers report having successfully deployed nonce-based policies.<ref>{{Cite web|url=https://www.eweek.com/security/how-google-is-using-content-security-policy-to-mitigate-web-flaws|title=How Google Is Using Content Security Policy to Mitigate Web Flaws|website=eWEEK|date=April 22, 2019 |access-date=2019-05-01}}</ref><ref name=OR_1>{{cite web| title=[CSP] On Reporting and Filtering| last=Akhawe| first=Devdatta| url=https://dropbox.tech/security/on-csp-reporting-and-filtering| publisher=[[Dropbox]]| date=21 September 2015| access-date=1 January 2024}}</ref>
===Emerging defensive technologies===
Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use [[static program analysis|static analysis]] and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping.<ref>L. K. Shar and H. B. K. Tan, "Automated removal of cross site scripting vulnerabilities in web applications," ''Information and Software Technology,'' vol. 54, ''(5),'' pp. 467-478, 2012.</ref>
===SameSite cookie parameter===
{{Main|Same-site cookie}}
When a cookie is set with the <code>SameSite=Strict</code> parameter, it is stripped from all cross-origin requests. When set with <code>SameSite=Lax</code>, it is stripped from all non-"safe" cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics).<ref>{{Cite journal|url=https://tools.ietf.org/html/draft-west-first-party-cookies-07|title=Same-site Cookies|last1=Mark|first1=Goodwin|last2=Mike|first2=West|website=tools.ietf.org|date=April 6, 2016 |language=en|access-date=2018-05-04}}</ref> The feature is implemented in [[Google Chrome]] since version 63 and [[Firefox]] since version 60.<ref>{{Cite web|url=https://caniuse.com/#feat=same-site-cookie-attribute|title=Can I use... Support tables for HTML5, CSS3, etc|website=caniuse.com|language=en-US|access-date=2018-05-04}}</ref>
== Notable incidents ==
* [[British Airways data breach]] (2018)
== See also ==
*[[Web application security]]
*[[Internet security]]
Line 196 ⟶ 146:
*[[Samy (computer worm)]]
*[[Parameter validation]]
== Footnotes ==
{{Notelist}}
==References==
Line 208 ⟶ 161:
*[[OWASP]]: [https://owasp.org/www-community/attacks/xss/ XSS], [http://www.owasp.org/index.php/Testing_for_Cross_site_scripting Testing for XSS], [http://www.owasp.org/index.php/Reviewing_Code_for_Cross-site_scripting Reviewing Code for XSS]
*[http://www.xssed.com/ XSSed: Database of Websites Vulnerable to Cross-Site Scripting Attacks]
{{Web interfaces}}
{{Information security}}
{{DEFAULTSORT:Cross-Site Scripting}}
Line 213 ⟶ 170:
[[Category:Injection exploits]]
[[Category:Hacking (computer security)]]
[[Category:Client-side web security exploits]]
| |||