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 "OWASP Periodic Table of Vulnerabilities - Cross-Site Scripting (XSS)"

From OWASP
Jump to: navigation, search
Line 5: Line 5:
 
=== Root Cause Summary ===
 
=== Root Cause Summary ===
  
 +
Cross-Site Scripting (aka XSS or CSS) is an injection type attack where a user injects a script such as  into a valid page that in turn will route the victim that activates the script, to a similar page where the entered data and/cookies can be captured. 
 +
The root cause of cross site scripting is accepting untrusted data. Accepting untrusted data can be prevented by validating and escaping data prior inserting the value into a SQL query or into output HTML.
  
 
=== Browser / Standards Solution ===
 
=== Browser / Standards Solution ===
Line 20: Line 22:
  
 
=== Discussion / Controversy ===
 
=== Discussion / Controversy ===
 +
While most of us use the acronym “CSS” for Cascading Style Sheets and “XSS” for Cross Site Scripting in some circles “CSS” is the acronym Cross Site Scripting.
 +
To make things even more convoluted it is possible to use perform a cross site scripting (XSS) attach on a Cascading style Sheet (CSS) that permit JavaScript code to be embedded in them.
  
  

Revision as of 20:04, 24 June 2013

Return to Periodic Table Working View

Cross-Site Scripting (XSS)

Root Cause Summary

Cross-Site Scripting (aka XSS or CSS) is an injection type attack where a user injects a script such as into a valid page that in turn will route the victim that activates the script, to a similar page where the entered data and/cookies can be captured. The root cause of cross site scripting is accepting untrusted data. Accepting untrusted data can be prevented by validating and escaping data prior inserting the value into a SQL query or into output HTML.

Browser / Standards Solution

Browser vendors and standards bodies should agree on markup for elements to contain dynamic content (e.g. Flash, JavaScript, HTML, etc.) inline without allowing the dynamic content to perform malicious actions such as navigating the parent window, reading or writing data across trust boundaries, or other undesirable behaviors as determined by the owner of the containing page.

Perimeter Solution

None

Generic Framework Solution

Automatically sanitize any dynamic content before writing it into HTML, XML, or other documents that might be rendered by user agents that execute active content. If dynamic content must include dangerous elements, provide APIs which filter and sanitize potentially dangerous attributes of these elements. Exceptions and attribute configurations should be described by a policy file instead of hard-coded into the framework itself or into function calls.

Custom Framework Solution

None

Custom Code Solution

None

Discussion / Controversy

While most of us use the acronym “CSS” for Cascading Style Sheets and “XSS” for Cross Site Scripting in some circles “CSS” is the acronym Cross Site Scripting. To make things even more convoluted it is possible to use perform a cross site scripting (XSS) attach on a Cascading style Sheet (CSS) that permit JavaScript code to be embedded in them.


References

OWASP Cross-site Scripting (XSS)

OWASP – XSS (Cross Site Scripting) Prevention Cheat Sheet

The Web Application Security Consortium – Cross Site Scripting

Common Attack Pattern Emulation and Classification – CAPEC-341: WASC Threat Classification 2.0 – WASC-8 – Cross-Site Scripting

cgisecurity - The Cross-Site Scripting (XSS) FAQ