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)
(→‎How to Protect Yourself)
Line 20: Line 20:
 
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.
 
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.
  
−
===How to Protect Yourself===
 
−
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:
 
−
 
−
{| border="1"
 
−
|+ 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.
 
−
 
−
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.
 
−
 
−
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.
 
  
 
==Risk Factors==
 
==Risk Factors==

Revision as of 14:46, 21 February 2009

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


Last revision (mm/dd/yy): 02/21/2009

Vulnerabilities Table of Contents

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.

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

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.


Risk Factors

TBD


Examples

TBD

Related Attacks


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

Retrieved from "https://wiki.owasp.org/index.php?title=Cross_Site_Scripting_Flaw&oldid=55211"