XSS (cross Site Scripting) prevention Cheat Sheet (XSS protection Checklist)

This article is a translated version of the XSS defense Checklist Https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

Introduction

This article describes a simple positive pattern that properly uses output transcoding or escaping (encoding or escaping) to defend against XSS attacks.

Despite the huge amount of XSS attacks, following some simple rules can completely prevent this kind of serious attack.

This article does not discuss the commercial and technical impact of XSS attacks.

reflected and stored XSS can be resolved as long as the appropriate authentication and escape is performed on the server side (validation and escaping). It is recommended to use the Escape transcoding library (ESAPI or the Microsoft anti-cross Site Scripting Library) because there are many special cases. Dom Based XSS attacks can be resolved using the DOM Based XSS prevention a specific subset of Cheat sheet.

For a checklist of XSS attack factors, refer to excellent XSS Cheat Sheet by Rsnake. For more information about browser security and the background of various browsers, please refer to Browser Security Handbook.

Before reading this checklist, it is necessary to understand the underlying injection theory (injection theory.).

a proactive model for XSS protection

This article sees HTML as a template with some slots, and developers can put untrusted data into slots. These slots cover a common place where most developers may put untrusted data. It is not allowed to put untrusted data elsewhere in the HTML. This is the whitelist mode, rejecting anything that is not explicitly allowed.

Considering how the browser parses the HTML, each of the different types of slots has a slightly different security rule. When you put untrusted data into a slot, you need to take some steps to make sure that the data does not break the slots and then into the context, allowing code execution.

In a sense, this approach regards HTML documents as parameterized database queries-data is stored at a specified location, and is isolated from the code context using escape.

This document describes the most common slot types, and rules for securely inserting untrusted data into slots. Based on a variety of different instructions, for XSS factors, and for performing a large number of manual tests on all popular browsers, we make sure that the rules here are safe.

Slots are defined, and each slot has some rules to provide. If developers do not have a very careful analysis, they should not (should not) put the data in other slots, so that their actions are safe. Browser parsing is extremely bizarre, and many seemingly harmless characters become huge holes in the right context.

Why can't I just use HTML entities to transcode non-trusted data?

HTML entity encoding is OK for putting untrusted data into the HTML document weight, for example in <div>.

However, HTML entity encoding is problematic for placing untrusted data anywhere in the <script> tag, or for event handling properties (such as onmouseover), or in CSS, which is in the URL. So even if you use HTML entity encoding anywhere, there may still be an XSS vulnerability. You must use the escape syntax for the HTML part that you want to insert untrusted data into. This is all that is involved in the following rules.

you need a secure transcoding library.

Writing an encoder is not particularly difficult, but there are a number of hidden flaws. For example, you might use escape shortcut notation in JS, but this value is dangerous and may be misunderstood by a nested parser in the browser. You may also forget to escape the "escape character", which an attacker can use to counteract your security efforts. OWASP recommends using a security-focused coding library to ensure that these rules are properly implemented.

The OWASP Esapi project creates an escape library that is implemented in a variety of languages, including Java, PHP, Classic ASP, Cold Fusion, Python, and Haskell.

Microsoft provides a transcoding library, Microsoft Anti-Cross Site Scripting Library for the. NET platform.

XSS Defense Rules

The following rules are intended to protect against all XSS in your app. Although these rules do not allow you to insert untrusted data anywhere in the HTML, it includes the vast majority of common use cases. You do not have to allow the use of all rules in your organization. Many organizations find it sufficient to allow rules 1 and 2 to be used (many organizations may find, allowing only rule #1 and rule #2 is sufficient for their needs< /c1>.). If you find that there are other environments where you can use escape to become safe, please feedback the discussion page.

Instead of simply escaping the list of characters from the examples in the various rules, it is not sufficient to escape those lists.

The blacklist approach is very fragile, and these whitelist rules are carefully designed to even provide protection against future vulnerabilities introduced by browsers.

rule #0 does not insert non-trusted data, Except in allowed Locations

The first rule is to deny everything (denyall). Do not insert untrusted input into an HTML document unless it is a rule #1 through rule #5定义的插槽之一.

The reason for this rule is that the browser has many strange HTML contexts so that the list of rules becomes very complex.

<script> ... Never PUT untrusted DATA here ... </script>   directly in a script  <!--... Never PUT untrusted DATA here ... --             inside an HTML comment ...   Never PUT untrusted DATA here ... =test/> In an       attribute name  <never PUT untrusted DATA here ... href= "/test"/> in   a TA G name  <style>... Never PUT untrusted DATA here ... </style>   directly in CSS

Most importantly, never accept actual JavaScript code from a untrusted source and then run it.

Rule # # # performs HTML escape before inserting non-trusted data into HTML element content

This rule corresponds to inserting untrusted data into some locations in the HTML body. Include normal tags such as div, p, B, TD, etc

Many web frameworks provide HTML escapes, characters that are detailed below, but this is absolutely not enough, for other HTML contexts,

You need to perform other rules that are detailed here,

<body> ... ESCAPE untrusted DATA before putting here ... </body>  <div>... ESCAPE untrusted DATA before putting here ... </div> any other  normal HTML elements

Escaping the following characters, using HTML entity encoding, prevents switching to any execution environment, such as script, style, or event handlers

Using hex entities is recommended in the specification (using hex entities is recommended in the spec.).

In addition to the five important characters in XML (&, <,;, ","), forward backslashes are also included because they help to close the HTML tag.

& &amp; < &lt; > &gt; "-&quot;"-& #x27;     &apos; is not recommended/-& #x2F;     Forward slash is included as it helps end an HTML entity

Refer to Esapi reference implementation, check HTML entity escape and invert semantics

String safe = Esapi.encoder (). encodeforhtml (Request.getparameter ("input"));

Rule # # # performs a property escape before inserting the non-trusted data into the common attributes of the HTML element

This rule, which corresponds to inserting untrusted data into a typical attribute value of an HTML element, such as width, name, value, etc.

This rule does not apply to complex HTML attribute values such as href, SRC, style, or any of the event handlers like onmouseover.

It is important to note that the escape processing of the event handling property values must follow Rule 3!

<div attr= ... ESCAPE untrusted DATA before putting here ... >content</div>     inside unquoted attribute  <div attr= '... ESCAPE untrusted DATA before puttinghere ... ' >content</div> inside single   quoted attribute  < Div attr= "... ESCAPE untrusted DATA before puttinghere ... " >content</div>   inside Double quoted attribute

In addition to numbers and letters, escape any other ASCII value less than 256 characters, the escape format is & #xHH; Or use named entity if it exists, this escaped organization switches out of the attribute range.

This rule is widely applied because developers tend to let attribute values without quotation marks. Attribute values with quotation marks, which only need to be escaped with the corresponding quotation marks, but not quoted attribute values, may be destroyed by many characters, including: [Space]% * +,-/; < = > ^ and |

Refer to Esapi reference implementation, check HTML entity escape and invert semantics

String safe = Esapi.encoder (). Encodeforhtmlattribute (Request.getparameter ("input"));

Rule # # # before inserting the non-trusted data to the JS data value, do JS escape

This rule focuses on dynamically generated JS code-including script code blocks and event handling properties.

The only way to safely place non-row data into your code is to put it in a referenced data value string, such as "data value."

Inserting non-trusted data in any other JS environment is dangerous because it is very easy to enter the execution environment, using the following characters (including but not limited to):

Semi-colon, Equals, space, plus, and many more

So use the extra care

<script>alert (' ... ESCAPE untrusted DATA before puttinghere ... ') </script>     inside a quoted string  <script>x= ' ... ESCAPE untrusted DATA before puttinghere ... ' </script> one          side of a quoted expression  <div onmouse Over= "x=" ... ESCAPE untrusted DATA before puttinghere ... ' "</div>  inside quoted event handler

！！！ Note that there are some JS functions, it is impossible to use the non-trusted data safely, even if you use JS Escape (even if JAVASCRIPT escaped!)

For example

<script> window.setinterval (' ... Even IF you ESCAPE untrusted DATA is xssed here ... '); </script>

In addition to alphanumeric, any other characters less than 256 are escaped, the escaped format is \XHH, which prevents the range of data values from being toggled, into the scripting environment, or into another property.

Do not use escape shortcuts \ "Because HTML uses a number as the attribute value range identifier.

This escape shortcut is also susceptible to "escape-the-escape" attacks, such as an attacker sending a \ "parser translated to \ \"

This activates the quotation marks as a function of the range of attribute values.

If the event handling handle value is enclosed in quotation marks, then breaking the environment requires using quotation marks.

But we deliberately make this rule a lot more widely, because developers often omit quotes.

Without the quoted attribute, the environment can be destroyed by a character, including but not limited to [space]% * +,-/; < = > ^ and |

At the same time, </script> closing tag closes a script block, even though it appears in double quotes, because the HTML parser is executed before the JS parser.

Refer to Esapi reference implementation for JS escape and invert semantics

String safe = Esapi.encoder (). Encodeforjavascript (Request.getparameter ("input"));

rule #3.1 html escaping in an HTML environment and reading data using json.parse

No research for the time being added

Rule # # # before inserting the non-trusted data into the HTML style property value, perform a CSS escape and strictly validate

No research for the time being added

Rule # # # to perform a URL escape before inserting the non-trusted data into the URL parameter value

In this rule, you should insert untrusted data into the URL, which is typically an http GET parameter.

<a href= "http://www.somesite.com?test= ... ESCAPE untrusted DATA before puttinghere ... ">link</a >       

In addition to alphanumeric, any other characters less than 256 need to be escaped, and the escaped format is%HH

The URL is not allowed as an output of non-row data because there is no good escape method to shut down the attack, which destroys the URL meaning.

All attributes should be enclosed in quotation marks.

Attributes that are not enclosed are easily destroyed by the following characters, including [space]% * +,-/; < = > ^ and |.

Note that entity transcoding is useless on URL property values.

Refer to Esapi Reference implementation for URL escaping and reversal semantics

String safe = Esapi.encoder (). Encodeforurl (Request.getparameter ("input"));

Rule # Use a dedicated library to clean out HTML tags

OWASP Antisamy

  Import org.owasp.validator.html.*;  Policy policy = policy.getinstance (policy_file_location);  Antisamy as = new Antisamy ();  Cleanresults cr = As.scan (dirtyinput, policy);  Myuserdao.storeuserprofile (cr.getcleanhtml ()); Some custom function

OWASP Java HTML Sanitizer

  Import org.owasp.html.Sanitizers;  Import org.owasp.html.PolicyFactory;  Policyfactory sanitizer = Sanitizers.FORMATTING.and (sanitizers.blocks);  String cleanresults = Sanitizer.sanitize ("<p>hello, <b>World!</b>");

For more information in OWASP Java HTML sanitizer policy construction, see http://owasp-java-html-sanitizer.googlecode.co M/svn/trunk/distrib/javadoc/org/owasp/html/sanitizers.html

Rule # # Defense Dom Based XSS attack

Refer to OWASP article on DOM based XSS prevention Cheat Sheet.

Additional Rule # # uses the httponly cookie logo

Preventing all XSS attacks is very difficult, as you can see. In order to mitigate the consequences of this harm,

Owasp recommends that session cookies and any cookies that are not scripted access be set to the HttpOnly identity.

For more details about the HttpOnly cookie flag, including what it does, and how to use it, see the OWASP article on HttpOnly .

Additional Rule # # executes content security Policy

There is another good complex solution to mitigate the impact of an XSS flaw called Content Security Policy.

Summary of XSS defense rules

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

Data Type	Context	Code Sample	Defense
String	HTML Body	<span>Untrusted data</span>	HTML Entity Encoding
String	Safe HTML Attributes	<input type= "text" name= "fname" value= "untrusted DATA" >	Aggressive HTML Entity Encoding Untrusted data into a whitelist of safe attributes (listed below). Strictly validate unsafe attributes such as background, ID and name.
String	GET Parameter	<a href= "/site/search?value=untrusted DATA" >clickme</a>	URL Encoding
String	Untrusted URL in a SRC or HREF attribute	<a href= "untrusted URL" >clickme</a> <iframe src= "untrusted URL"/>	Canonicalize input URL Validation Safe URL Verification Whitelist http and HTTPS URL ' s only (Avoid the JavaScript Protocol to Open a new Window) Attribute Encoder
String	CSS Value	<div style= "width: untrusted DATA;" >Selection</div>	Strict Structural Validation CSS HEX Encoding Good design of CSS Features
String	JavaScript Variable	<script>var currentvalue= 'untrusted DATA ';</script> <script>somefunction ('untrusted DATA ');</script>	Ensure JavaScript variables is quoted JavaScript Hex Encoding JavaScript Unicode Encoding Avoid backslash encoding (\ "or \" or \ \)
Html	HTML Body	<div>Untrusted html</div>	HTML Validation (Jsoup, Antisamy, HTML sanitizer)
String	DOM XSS	<script>document.write ("untrusted INPUT:" + document.location.hash);<script/>	DOM based XSS Prevention Cheat Sheet

Safe HTML Attributes include: align, ALink, Alt, bgcolor, border, cellpadding, cellspacing, class, Color, cols, c Olspan, coords, dir, face, height, hspace, ismap, Lang, marginheight, marginwidth, multiple, nohref, noresize, NoShade, no Wrap, ref, REL, rev, rows, rowspan, scrolling, shape, span, summary, TabIndex, title, Usemap, valign, value, Vlink, vspace , width

Summary of output transcoding rules

The purpose of output encoding (as it relates to cross Site Scripting) are to convert untrusted input into a safe form wher E The input is displayed as data to the user without executing as code in the browser. The following charts details a list of critical output encoding methods needed to stop cross Site Scripting.

Encoding Type	Encoding mechanism
HTML Entity Encoding	Convert & To &amp; Convert < to &lt; Convert > to &gt; Convert "to &quot; Convert ' to & #x27; Convert/to & #x2F;
HTML Attribute Encoding	Except for alphanumeric characters, escape all characters with the HTML Entity & #xHH; format, including spaces. (HH = Hex Value)
URL Encoding	Standard percent encoding, see:http://www.w3schools.com/tags/ref_urlencode.asp. URL encoding should only is used to encode parameter values, not the entire URL or path fragments of a URL.
JavaScript Encoding	Except for alphanumeric characters, escape all characters with the \uxxxx Unicode escaping format (X = Integer).
CSS Hex Encoding	CSS escaping supports \xx and \xxxxxx. Using A, character escape can cause problems if the next character continues the escape sequence. There is solutions (a) Add a space after the CSS escape ('ll be ignored by the CSS parser) (b) Use the full amount O F CSS escaping possible by zero padding the value.

 

related articles

XSS Attack Cheat Sheet

The following article describes how to exploit different kinds of XSS vulnerabilities which this article is created to Hel P You avoid:

• OWASP:XSS Filter Evasion Cheat sheet-based on-rsnake ' s: "XSS Cheat Sheet"

A systematic analysis of XSS sanitization in Web application frameworks

Http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf

Description of XSS Vulnerabilities

• OWASP article on XSS vulnerabilities

Discussion on the Types of XSS vulnerabilities

• Types of Cross-site Scripting

How to Review Code for cross-site scripting vulnerabilities

• OWASP Code Review Guide article on reviewing code for Cross-site scripting vulnerabilities

How to Test for Cross-site scripting vulnerabilities

• OWASP Testing Guide article on testing for cross site scripting vulnerabilities

• XSS experimental Minimal Encoding Rules

Authors and Primary Editors

Jeff williams-jeff.williams[at]owasp.org
Jim manico-jim[at]owasp.org
Neil mattatall-neil[at]owasp.org

Other cheatsheets

Developer Cheat Sheets (Builder)

• Authentication Cheat Sheet
• Choosing and Using Security Questions Cheat Sheet
• Clickjacking Defense Cheat Sheet
• c-based Toolchain Hardening Cheat Sheet
• Cross-site Request Forgery (CSRF) prevention Cheat Sheet
• Cryptographic Storage Cheat Sheet
• DOM based XSS Prevention Cheat Sheet
• Forgot Password Cheat Sheet
• HTML5 Security Cheat Sheet
• Input Validation Cheat Sheet
• JAAS Cheat Sheet
• Logging Cheat Sheet
• . NET Security Cheat Sheet
• Password Storage Cheat Sheet
• Pinning Cheat Sheet
• Query Parameterization Cheat Sheet
• Ruby on Rails cheatsheet
• REST Security Cheat Sheet
• Session Management Cheat Sheet
• SQL Injection Prevention Cheat Sheet
• Transport Layer Protection Cheat Sheet
• Unvalidated redirects and forwards Cheat Sheet
• User Privacy Protection Cheat Sheet
• Web Service Security Cheat Sheet
• XSS (Cross Site Scripting) prevention Cheat Sheet

Assessment Cheat Sheets (breaker)

• Attack Surface Analysis Cheat Sheet
• XSS Filter Evasion Cheat Sheet
• REST Assessment Cheat Sheet

Mobile Cheat Sheets

• IOS Developer Cheat Sheet
• Mobile Jailbreaking Cheat Sheet

OpSec Cheat Sheets (Defender)

• Virtual Patching Cheat Sheet

Draft Cheat Sheets

• OWASP Top Ten Cheat Sheet
• Access Control Cheat Sheet
• Application Security Architecture Cheat Sheet
• Business Logic Security Cheat Sheet
• PHP Security Cheat Sheet
• Secure Coding Cheat Sheet
• Secure SDLC Cheat Sheet
• Threat Modeling Cheat Sheet
• WEB Application Security Testing Cheat Sheet
• Grails Secure Code Review Cheat Sheet
• IOS Application Security Testing Cheat Sheet
• Key Management Cheat Sheet
• Insecure Direct Object Reference Prevention Cheat Sheet
• Content Security Policy Cheat Sheet

XSS (cross Site Scripting) prevention Cheat Sheet (XSS protection Checklist)