diff --git a/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md b/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md index 05331cbd32..dda3bedcbf 100644 --- a/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md +++ b/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md @@ -2,17 +2,17 @@ ## Introduction -This cheat sheet provides guidance to prevent XSS vulnerabilities. +This cheat sheet helps developers prevent XSS vulnerabilities. -Cross-Site Scripting (XSS) is a misnomer. The name originated from early versions of the attack where stealing data cross-site was the primary focus. Since then, it has extended to include injection of basically any content, but we still refer to this as XSS. XSS is serious and can lead to account impersonation, observing user behaviour, loading external content, stealing sensitive data, and more. +Cross-Site Scripting (XSS) is a misnomer. Originally this term was derived from from early versions of the attack that were primarily focused on stealing data cross-site. Since then, the term has widened to include injection of basically any content. XSS attacks are serious and can lead to account impersonation, observing user behaviour, loading external content, stealing sensitive data, and more. -**This cheatsheet is a list of techniques to prevent or limit the impact of XSS. No single technique will solve XSS. Using the right combination of defensive techniques is necessary to prevent XSS.** +**This cheatsheet contains techniques to prevent or limit the impact of XSS. Since no single technique will solve XSS, using the right combination of defensive techniques will be necessary to prevent XSS.** ## Framework Security -Fewer XSS bugs appear in applications built with modern web frameworks. These frameworks steer developers towards good security practices and help mitigate XSS by using templating, auto-escaping, and more. That said, developers need to be aware of problems that can occur when using frameworks insecurely such as: +Fortunately, applications built with modern web frameworks have fewer XSS bugs, because these frameworks steer developers towards good security practices and help mitigate XSS by using templating, auto-escaping, and more. However, developers need to know that problems can occur if frameworks are used insecurely, such as: -- *escape hatches* that frameworks use to directly manipulate the DOM +- _escape hatches_ that frameworks use to directly manipulate the DOM - React’s `dangerouslySetInnerHTML` without sanitising the HTML - React cannot handle `javascript:` or `data:` URLs without specialized validation - Angular’s `bypassSecurityTrustAs*` functions @@ -20,19 +20,19 @@ Fewer XSS bugs appear in applications built with modern web frameworks. These fr - Out of date framework plugins or components - and more -Understand how your framework prevents XSS and where it has gaps. There will be times where you need to do something outside the protection provided by your framework. This is where Output Encoding and HTML Sanitization are critical. OWASP are producing framework specific cheatsheets for React, Vue, and Angular. +When you use a modern web framework, you need to know how your framework prevents XSS and where it has gaps. There will be times where you need to do something outside the protection provided by your framework, which means that Output Encoding and HTML Sanitization can be critical. OWASP will be producing framework specific cheatsheets for React, Vue, and Angular. ## XSS Defense Philosophy -For XSS attacks to be successful, an attacker needs to insert and execute malicious content in a webpage. Each variable in a web application needs to be protected. Ensuring that **all variables** go through validation and are then escaped or sanitized is known as perfect injection resistance. Any variable that does not go through this process is a potential weakness. Frameworks make it easy to ensure variables are correctly validated and escaped or sanitised. +In order for an XSS attack to be successful, an attacker must be able to to insert and execute malicious content in a webpage. Thus, all variables in a web application needs to be protected. Ensuring that **all variables** go through validation and are then escaped or sanitized is known as **perfect injection resistance**. Any variable that does not go through this process is a potential weakness. Frameworks make it easy to ensure variables are correctly validated and escaped or sanitised. -However, frameworks aren't perfect and security gaps still exist in popular frameworks like React and Angular. Output Encoding and HTML Sanitization help address those gaps. +However, no framework is perfect and security gaps still exist in popular frameworks like React and Angular. Output encoding and HTML sanitization help address those gaps. ## Output Encoding -Output Encoding is recommended when you need to safely display data exactly as a user typed it in. Variables should not be interpreted as code instead of text. This section covers each form of output encoding, where to use it, and where to avoid using dynamic variables entirely. +When you need to safely display data exactly as a user types it in, output encoding is recommended. Variables should not be interpreted as code instead of text. This section covers each form of output encoding, where to use it, and when you should not use dynamic variables at all. -Start with using your framework’s default output encoding protection when you wish to display data as the user typed it in. Automatic encoding and escaping functions are built into most frameworks. +First, when you wish to display data as the user typed it in, start with your framework’s default output encoding protection. Automatic encoding and escaping functions are built into most frameworks. If you’re not using a framework or need to cover gaps in the framework then you should use an output encoding library. Each variable used in the user interface should be passed through an output encoding function. A list of output encoding libraries is included in the appendix. @@ -40,23 +40,23 @@ There are many different output encoding methods because browsers parse HTML, JS ### Output Encoding for “HTML Contexts” -“HTML Context” refers to inserting a variable between two basic HTML tags like a `
` or ``. For example.. +“HTML Context” refers to inserting a variable between two basic HTML tags like a `
` or ``. For example: ```HTML
$varUnsafe
``` -An attacker could modify data that is rendered as `$varUnsafe`. This could lead to an attack being added to a webpage.. for example. +An attacker could modify data that is rendered as `$varUnsafe`. This could lead to an attack being added to a webpage. For example: ```HTML
// Example Attack ``` -In order to add a variable to a HTML context safely, use HTML entity encoding for that variable as you add it to a web template. +In order to add a variable to a HTML context safely to a web template, use HTML entity encoding for that variable. -Here are some examples of encoded values for specific characters. +Here are some examples of encoded values for specific characters: -If you're using JavaScript for writing to HTML, look at the `.textContent` attribute as it is a **Safe Sink** and will automatically HTML Entity Encode. +If you're using JavaScript for writing to HTML, look at the `.textContent` attribute. It is a **Safe Sink** and will automatically HTML Entity Encode. ```HTML & & @@ -68,22 +68,22 @@ If you're using JavaScript for writing to HTML, look at the `.textContent` attri ### Output Encoding for “HTML Attribute Contexts” -“HTML Attribute Contexts” refer to placing a variable in an HTML attribute value. You may want to do this to change a hyperlink, hide an element, add alt-text for an image, or change inline CSS styles. You should apply HTML attribute encoding to variables being placed in most HTML attributes. A list of safe HTML attributes is provided in the **Safe Sinks** section. +“HTML Attribute Contexts” occur when a variable is placed in an HTML attribute value. You may want to do this to change a hyperlink, hide an element, add alt-text for an image, or change inline CSS styles. You should apply HTML attribute encoding to variables being placed in most HTML attributes. A list of safe HTML attributes is provided in the **Safe Sinks** section. ```HTML
// Example Attack ``` -It’s critical to use quotation marks like `"` or `'` to surround your variables. Quoting makes it difficult to change the context a variable operates in, which helps prevent XSS. Quoting also significantly reduces the characterset that you need to encode, making your application more reliable and the encoding easier to implement. +**It’s critical to use quotation marks like `"` or `'` to surround your variables.** Quoting makes it difficult to change the context a variable operates in, which helps prevent XSS. Quoting also significantly reduces the characterset that you need to encode, making your application more reliable and the encoding easier to implement. -If you're using JavaScript for writing to a HTML Attribute, look at the `.setAttribute` and `[attribute]` methods which will automatically HTML Attribute Encode. Those are **Safe Sinks** as long as the attribute name is hardcoded and innocuous, like `id` or `class`. Generally, attributes that accept JavaScript, such as `onClick`, are **NOT safe** to use with untrusted attribute values. +If you're writing to a HTML Attribute with JavaScript, look at the `.setAttribute` and `[attribute]` methods because they will automatically HTML Attribute Encode. Those are **Safe Sinks** as long as the attribute name is hardcoded and innocuous, like `id` or `class`. Generally, attributes that accept JavaScript, such as `onClick`, are **NOT safe** to use with untrusted attribute values. ### Output Encoding for “JavaScript Contexts” -“JavaScript Contexts” refer to placing variables into inline JavaScript which is then embedded in an HTML document. This is commonly seen in programs that heavily use custom JavaScript embedded in their web pages. +“JavaScript Contexts” refers to the situation where variables are placed into inline JavaScript and then embedded in an HTML document. This situation commonly occurs in programs that heavily use custom JavaScript that is embedded in their web pages. -The only ‘safe’ location for placing variables in JavaScript is inside a “quoted data value”. All other contexts are unsafe and you should not place variable data in them. +However, the only ‘safe’ location for placing variables in JavaScript is inside a “quoted data value”. All other contexts are unsafe and you should not place variable data in them. Examples of “Quoted Data Values” @@ -101,7 +101,7 @@ For JSON, verify that the `Content-Type` header is `application/json` and not `t ### Output Encoding for “CSS Contexts” -“CSS Contexts” refer to variables placed into inline CSS. This is common when you want users to be able to customize the look and feel of their webpages. CSS is surprisingly powerful and has been used for many types of attacks. Variables should only be placed in a CSS property value. Other “CSS Contexts” are unsafe and you should not place variable data in them. +“CSS Contexts” refer to variables placed into inline CSS, which is common when developers want their users to customize the look and feel of their webpages. Since CSS is surprisingly powerful, it has been used for many types of attacks. **Variables should only be placed in a CSS property value. Other “CSS Contexts” are unsafe and you should not place variable data in them.** ```HTML @@ -146,7 +146,7 @@ Output encoding is not perfect. It will not always prevent XSS. These locations ``` -Other areas to be careful of include: +Other areas to be careful with include: - Callback functions - Where URLs are handled in code such as this CSS { background-url : “javascript:alert(xss)”; } @@ -157,7 +157,7 @@ Don't place variables into dangerous contexts as even with output encoding, it w ## HTML Sanitization -Sometimes users need to author HTML. One scenario would be allow users to change the styling or structure of content inside a WYSIWYG editor. Output encoding here will prevent XSS, but it will break the intended functionality of the application. The styling will not be rendered. In these cases, HTML Sanitization should be used. +When users need to author HTML, developers may let users change the styling or structure of content inside a WYSIWYG editor. Output encoding in this case will prevent XSS, but it will break the intended functionality of the application. The styling will not be rendered. In these cases, HTML Sanitization should be used. HTML Sanitization will strip dangerous HTML from a variable and return a safe string of HTML. OWASP recommends [DOMPurify](https://github.com/cure53/DOMPurify) for HTML Sanitization. @@ -204,36 +204,72 @@ Consider adopting the following controls in addition to the above. ### XSS Prevention Rules Summary -The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts. +These snippets of HTML demonstrate how to render untrusted data safely in a variety of different contexts. -| Data Type | Context | Code Sample | Defense | -|-----------|------------------------------------------|--------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| String | HTML Body | `UNTRUSTED DATA ` | HTML Entity Encoding (rule \#1). | -| String | Safe HTML Attributes | `` | Aggressive HTML Entity Encoding (rule \#2), Only place untrusted data into a list of safe attributes (listed below), Strictly validate unsafe attributes such as background, ID and name. | -| String | GET Parameter | `clickme` | URL Encoding (rule \#5). | -| String | Untrusted URL in a SRC or HREF attribute | `clickme