This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Cross Site Scripting Flaw"

From OWASP
Jump to: navigation, search
(Description)
(References)
 
(9 intermediate revisions by 5 users not shown)
Line 6: Line 6:
  
 
==Description==
 
==Description==
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
+
Cross site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into otherwise benign and trusted web sites. Cross site scripting flaws are the most prevalent flaw in web applications today. Cross site scripting attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
  
 
Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.
 
Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.
Line 18: Line 18:
  
 
===How to Determine If You Are Vulnerable===
 
===How to Determine If You Are Vulnerable===
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.
+
There are three known types of cross site scripting: [[Cross-site_Scripting_(XSS)#Reflected_XSS_Attacks | reflected]], [[Cross-site_Scripting_(XSS)#Stored_XSS_Attacks | stored]], and [[DOM_Based_XSS | DOM injection]]. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:
  
===How to Protect Yourself===
+
echo $_REQUEST['userinput'];
The best way to protect a web application from XSS attacks is ensure that your application performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed. The validation should not attempt to identify active content and remove, filter, or sanitize it. There are too many types of active content and too many ways of encoding it to get around filters for such content. We strongly recommend a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack signature based policies are difficult to maintain and are likely to be incomplete.
 
  
Encoding user supplied output can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form. Applications can gain significant protection from javascript based attacks by converting the following characters in all generated output to the appropriate HTML entity encoding:
+
Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unfiltered. This is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals.
  
{| border="1"
+
With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. Alternatively, attacks can be a blend or hybrid of all three types. The danger with cross site scripting is not the type of attack, but that it is possible.
|+ HTML Entities
 
! Character !! Encoding
 
|-
 
| < || &amp;lt; or &amp;#60;
 
|-
 
| > || &amp;gt; or &amp;#62;
 
|-
 
| & || &amp;amp; or &amp;#38;
 
|-
 
| " || &amp;quot; or &amp;#34;
 
|-
 
| ' || &amp;apos; or &amp;#39;
 
|-
 
| ( || &amp;#40;
 
|-
 
| ) || &amp;#41;
 
|-
 
| # || &amp;#35;
 
|-
 
| % || &amp;#37;
 
|-
 
| ; || &amp;#59;
 
|-
 
| + || &amp;#43;
 
|-
 
| - || &amp;#45;
 
|}
 
  
This list is an example of dangerous characters. Do not be lured into thinking that output encoding via blacklisting is sufficient for XSS protection. The HTMLEntityEncode function at [http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java] is a whitelist HTML Entity Output Encoding mechanism for Java.
+
Attacks are usually implemented in JavaScript, which is a powerful scripting language. Using JavaScript allows attackers to manipulate any aspect of the rendered page, including adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies, even if victim site does not use AJAX today.  
  
Also, it's crucial that you turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported on the client. This attack is mounted when a user post a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the users cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all webservers.
+
Using XmlHttpRequest (AJAX), it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites, and to create complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible or require user interaction to perform dangerous cross site request forgery (CSRF) attacks (see [[CSRF]]).
  
The [[:Category:OWASP Filters Project|OWASP Filters project]] is producing reusable components in several languages to help prevent many forms of parameter tampering, including the injection of XSS attacks. In addition, the [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] training program has lessons on Cross-Site Scripting and data encoding.
+
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface.
  
 +
==Prevention==
 +
OWASP's recommended defenses against XSS are documented in the OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]].
 +
<!--
 
==Risk Factors==
 
==Risk Factors==
  
 
TBD
 
TBD
 
+
-->
  
 
==Examples==
 
==Examples==
 
+
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206 
TBD
+
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966 
 +
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204 
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
 
* [[Cross-site Scripting (XSS)]]
 
* [[Cross-site Scripting (XSS)]]
 
+
* [[Cross Site History Manipulation (XSHM)]]
 
+
<!--
 
 
 
==Related [[Vulnerabilities]]==
 
==Related [[Vulnerabilities]]==
 
* [[Vulnerability 1]]
 
* [[Vulnerability 1]]
 
* [[Vulnerabiltiy 2]]
 
* [[Vulnerabiltiy 2]]
 
  
 
==Related [[Controls]]==
 
==Related [[Controls]]==
 
* [[Control 1]]
 
* [[Control 1]]
 
* [[Control 2]]
 
* [[Control 2]]
 
  
 
==Related [[Technical Impacts]]==
 
==Related [[Technical Impacts]]==
 
* [[Technical Impact 1]]
 
* [[Technical Impact 1]]
 
* [[Technical Impact 2]]
 
* [[Technical Impact 2]]
 
+
-->
  
 
==References==
 
==References==
 +
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
 +
* OWASP Guide to Building Secure Web Applications and Web Services, [[Data Validation]]
 +
* OWASP Testing Guide, [[Testing for Cross site scripting]]
 
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml  
 
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml  
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
+
* XSS Cheat Sheet: [[XSS Filter Evasion Cheat Sheet]] New home for the old: ha.ckers.org/xss.html site.
 
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html  
 
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html  
* CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html  
+
* CERT "Understanding Malicious Content Mitigation" http://www.cert.org/tech_tips/malicious_code_mitigation.html  
* Cross-Site Scripting Security Exposure Executive Summary: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/ExSumCS.asp
 
 
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html  
 
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html  
* OWASP Guide to Building Secure Web Applications and Web Services, [[Data Validation]]
 
* OWASP Testing Guide, [[Testing for Cross site scripting]]
 
 
* [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation with Stinger)]]
 
* [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation with Stinger)]]
* Have Your Cake and Eat it Too (.NET validation) http://www.owasp.org/columns/jpoteet/jpoteet2
 
 
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com  
 
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com  
 +
* Cross-Site Scripting Security Exposure Executive Summary: http://technet.microsoft.com/en-us/library/cc750326.aspx
 +
* [[Have Your Cake and Eat It Too]] (.NET request validation)
  
 
[[Category:FIXME|add links
 
[[Category:FIXME|add links
 
+
<nowiki>[[Category:Input Validation Vulnerability]]</nowiki>
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
+
]]
 
 
Availability Vulnerability
 
 
 
Authorization Vulnerability
 
 
 
Authentication Vulnerability
 
 
 
Concurrency Vulnerability
 
 
 
Configuration Vulnerability
 
 
 
Cryptographic Vulnerability
 
 
 
Encoding Vulnerability
 
 
 
Error Handling Vulnerability
 
 
 
Input Validation Vulnerability
 
 
 
Logging and Auditing Vulnerability
 
 
 
Session Management Vulnerability]]
 
  
 
__NOTOC__
 
__NOTOC__
 
  
 
[[Category:OWASP ASDR Project]]
 
[[Category:OWASP ASDR Project]]
[[Category:OWASP Top Ten Project]]
 
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 +
[[Category:Externally Linked Page]]

Latest revision as of 01:46, 14 September 2013

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Last revision (mm/dd/yy): 09/14/2013

Vulnerabilities Table of Contents

Description

Cross site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into otherwise benign and trusted web sites. Cross site scripting flaws are the most prevalent flaw in web applications today. Cross site scripting attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

Attackers frequently use a variety of methods to encode the malicious portion of the tag, such as using Unicode, so the request is less suspicious looking to the user. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols. For this reason, attempting to “filter out” these scripts is not likely to succeed. Instead we recommend validating input against a rigorous positive specification of what is expected. XSS attacks usually come in the form of embedded JavaScript. However, any embedded active content is a potential source of danger, including: ActiveX (OLE), VBscript, Shockwave, Flash and more.

XSS issues can also be present in the underlying web and application servers as well. Most web and application servers generate simple web pages to display in the case of various errors, such as a 404 ‘page not found’ or a 500 ‘internal server error.’ If these pages reflect back any information from the user’s request, such as the URL they were trying to access, they may be vulnerable to a reflected XSS attack.

The likelihood that a site contains XSS vulnerabilities is extremely high. There are a wide variety of ways to trick web applications into relaying malicious scripts. Developers that attempt to filter out the malicious parts of these requests are very likely to overlook possible attacks or encodings. Finding these flaws is not tremendously difficult for attackers, as all they need is a browser and some time. There are numerous free tools available that help hackers find these flaws as well as carefully craft and inject XSS attacks into a target site.

Environments Affected

All web servers, application servers, and web application environments are susceptible to cross site scripting.

How to Determine If You Are Vulnerable

There are three known types of cross site scripting: reflected, stored, and DOM injection. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user:

echo $_REQUEST['userinput'];

Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unfiltered. This is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals.

With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. Alternatively, attacks can be a blend or hybrid of all three types. The danger with cross site scripting is not the type of attack, but that it is possible.

Attacks are usually implemented in JavaScript, which is a powerful scripting language. Using JavaScript allows attackers to manipulate any aspect of the rendered page, including adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies, even if victim site does not use AJAX today.

Using XmlHttpRequest (AJAX), it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites, and to create complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible or require user interaction to perform dangerous cross site request forgery (CSRF) attacks (see CSRF).

XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface.

Prevention

OWASP's recommended defenses against XSS are documented in the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.

Examples

Related Attacks

References