XSS (Cross Site Scripting) Prevention Cheat Sheet(XSS防护检查单)

本文是 XSS防御检查单的翻译版本 https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

介绍

本文描述了一种恰当地使用输出转码或者转义（encoding or escaping）防御XSS攻击的简单积极模式。

尽管存在巨量XSS攻击方式，遵守一些简单的规则能够彻底防住这类严重的攻击。

本文不探讨XSS攻击的商业和技术影响。

reflected and stored XSS 可以被解决，只要在服务器端执行合适的验证和转义（validation and escaping）。推荐使用转义转码库（ESAPI or the Microsoft Anti-Cross Site Scripting Library），因为存在很多特殊案例。DOM Based XSS攻击可以被解决， 使用DOM based XSS Prevention Cheat Sheet的特定子集。

关于XSS攻击因素的检查单，请参考优秀的 XSS Cheat Sheet by RSnake. 更多的介绍浏览器安全和各种浏览器的背景，请参考 Browser Security Handbook.

在阅读本检查单前， 有必要了解基础的注入理论（Injection Theory.）。

一个积极的XSS防护模型

本文将HTML看做为一个模板，带有一些插槽（slot）， 开发者可以将不可信数据放入插槽。这些插槽覆盖了绝大多数开发者可能将不可信数据放入的通用地方。将不可信数据放到HTML其他地方是不被允许的。 这是白名单模式， 拒绝不被明确允许的任何事情。

考虑到浏览器解析HTML的方式， 每种不同类型的插槽都有些许不同的安全规则。当你将不可信数据放入插槽，需要采取某些步骤，确保数据不会破坏插槽，进而进入上下文环境，允许代码执行。

某种意义上讲，这种方法将HTML文档看做是参数化的数据库查询 - 数据保存在指定位置， 使用转义与代码上下文隔离开来。

本文描述最通常的插槽类型，和将不可信数据安全地插入插槽的规则。基于各种不同说明，为XSS因素， 和对所有流行的浏览器执行大量的手动测试，我们确定这里提出规则是安全的。

插槽被定义，每一个插槽都有一些规则提供。开发者如果没有非常仔细的分析，不应该（SHOULD NOT）把数据放到其他的插槽中，这样保证他们的所作所为是安全的。浏览器解析是极其奇异的， 很多看似无害的字符在正确的上下文中变成巨大的漏洞。

为什么不能仅仅使用HTML实体转码不可信数据？

HTML实体编码是OK的，对于将不可信数据放到HTML文档体重，例如放到<div>中。

但是HTML实体编码是有问题的，对于将不可信数据放入<script>标签中的任何地方，或者事件处理属性（例如onmouseover），或者在CSS中， 后者在URL中。 所以即使你在任何地方使用HTML实体编码， 仍然可能存在XSS漏洞。你必须使用转义语法，对于你想将不可信数据插入的HTML部分。 这就是下面规则所涉及的全部。

你需要一个安全的转码库

写一个编码器不是特别困难， 但是存在不少隐藏的缺陷。 例如， 你可能在JS中使用转义快捷写法 \"， 但是这个值是危险的， 并且可能被浏览器中嵌套的解析器误解。你也有可能忘记转义“转义字符”， 攻击者可以利用抵消你的安全性努力。OWASP推荐使用关注安全的编码库， 保证这些规则被合理实现。

OWASP ESAPI 项目创建了一个转义库， 使用各种语言实现， 包括 Java, PHP, Classic ASP, Cold Fusion, Python, and Haskell.

Microsoft提供了一个转码库， Microsoft Anti-Cross Site Scripting Library for the .NET platform.

XSS防御规则

下面的规则目的是为了防御你应用中的所有XSS。尽管这些规则不允许将不可信数据插入到HTML中任何位置， 但是其包括了绝大多数通常使用案例。你在你的组织中不必要允许所有规则的使用。很多组织发现允许使用规则1和2就足够了（Many organizations may find that allowing only Rule #1 and Rule #2 are sufficient for their needs.）。如果你发现有其他的环境，可以使用转义变为安全的， 请反馈的讨论页面。

不要简单地转义各种规则中例子的字符列表，只转义那些列表是不够的。

黑名单方法是非常脆弱的， 这些白名单规则，经过仔细的设计， 甚至提供保护浏览器将来引入的漏洞。

规则#0 不插入不可信数据， Except in Allowed Locations

第一个规则是拒绝一切（deny all）。 不要将不可信输入插入HTML文档中，除非它是 Rule #1 through Rule #5定义的插槽之一。

本规则的原因是，浏览器有很多奇怪的HTML上下文， 以至于规则列表变得非常复杂。

<script>...NEVER PUT UNTRUSTED DATA HERE...</script>   directly in a script

 <!--...NEVER PUT UNTRUSTED DATA HERE...-->             inside an HTML comment

 <div ...NEVER PUT UNTRUSTED DATA HERE...=test />       in an attribute name

 <NEVER PUT UNTRUSTED DATA HERE... href="/test" />   in a tag name

 <style>...NEVER PUT UNTRUSTED DATA HERE...</style>   directly in CSS

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

规则#1 在插入不可信数据到HTML元素内容前，执行HTML转义

本规则对应，将不可信数据插入到HTML体中某些位置。包括正常的标签中，例如div, p, b, td, etc

很多web框架都提供了 HTML转义， 如下详述的字符， 但是这是绝对不够的，对于其它的HTML上下文，

你需要执行其它此处详述的规则，

 <body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>

 <div>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</div>

 any other normal HTML elements

转义下述字符，使用HTML实体编码方法， 可以阻止切换到任何执行环境，例如 script, style, or event handlers

使用HEX实体是被推荐的在规范中（Using hex entities is recommended in the spec.）。

除了XML中五个重要字符(&, <, >, ", ‘),  正向反斜杠也被包括进来， 因为其有助于闭合HTML标签。

 & --> &amp;
 < --> &lt;
 > --> &gt;
 " --> &quot;
 ‘ --> '     &apos; is not recommended
 / --> /     forward slash is included as it helps end an HTML entity

参考 ESAPI reference implementation ，查阅HTML实体转义和反转义

String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

规则#2 在插入不可信数据到HTML元素通用属性前，执行属性转义

本规则， 对应将不可信数据插入HTML元素典型属性值中，例如 width, name, value, etc。

本规则，不适用复杂的HTML属性值， 例如 href, src, style, or any of the event handlers like onmouseover.

非常重要地说明 事件处理属性值的转义处理， 必须遵从 规则3！

<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div>     inside UNquoted attribute

 <div attr=‘...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...‘>content</div>   inside single quoted attribute

 <div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content</div>   inside double quoted attribute

除了数字和字母， 转义其他的任何ASCII值小于256的字符， 转义格式为 &#xHH; 或者使用 named entity如果存在， 此转义组织切换出属性范围。

此规则应用广泛， 由于开发者往往让属性值不带引号。 带有引号的属性值，只需要对相应的引号转义即可； 但是不带引号的属性值， 可能被很多字符破坏， 包括： [space] % * + , - / ; < = > ^ and |

参考 ESAPI reference implementation ，查阅HTML实体转义和反转义

 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

规则#3 在插入不可信数据到JS数据值前，执行JS转义

本规则，关注动态生成的JS代码 -- 包括 script代码块 和 事件处理属性。

唯一安全放置不可行数据到代码中的方法是 放到引用的 数据值字符串中，例如 "data value."

在任何其它JS环境中插入不可信数据都是危险的， 因为其非常容易进入执行环境， 使用如下字符(包括但是不限与)：

semi-colon, equals, space, plus, and many more

所以使用上格外小心

<script>alert(‘...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...‘)</script>     inside a quoted string

 <script>x=‘...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...‘</script>          one side of a quoted expression

 <div onmouseover="x=‘...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...‘"</div>  inside quoted event handler

！！！ 请注意， 存在一些JS函数， 它不可能安全地使用不可信数据， 即使使用 JS转义 （EVEN IF JAVASCRIPT ESCAPED!）

例如

 <script>
 window.setInterval(‘...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...‘);
 </script>

除了 字母数字， 其他任何小于二五六的字符都要进行转义， 转义的格式为 \xHH， 防止切换出数据值范围， 到脚本环境， 或者进入另外一个属性。

不要使用转义捷径 \" ， 因为HTML中使用一号作为 属性值范围标识。

这个转义捷径， 还容易遭受 "escape-the-escape" 攻击， 例如攻击者发送了 \"， 解析器翻译为  \\"

这样就激活了 引号作为 属性值范围 的作用了。

如果事件处理句柄值使用引号括起来的， 那么破除这个环境需要使用引号。

但是我们有意使得此规则影响广泛， 因为开发者常常会将引号省略。

没有带引号的属性， 可以被一下字符破除环境 ， 包括但是不限于  [space] % * + , - / ; < = > ^ and |

同时， </script> closing tag会关闭一个script块， 尽管它是出现在双引号中， 因为HTML解析器比JS解析器执行靠前。

参考 ESAPI reference implementation ，查阅JS转义和反转义

String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

规则#3.1 在HTML环境中执行HTML转义，并使用JSON.parse读取数据

暂时无研究， 待添加

规则#4 在插入不可信数据到HTML style属性值之前，执行CSS转义并严格校验

暂时无研究，待添加

规则#5 在插入不可信数据到URL参数值之前，执行URL转义

本规则，应对将不可信数据插入URL中，一般是HTTP GET 参数。

 <a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

除了字母数字， 其他任何小于256的字符都需要进行转义， 转义格式为 %HH

URL不允许作为不可行数据输出， 因为没有好的转义方法关闭掉这种攻击，攻击会破坏URL含义。

所有属性应该被引号括起来。

没有括起来的属性很容易被以下字符破坏属性范围，  包括 [space] % * + , - / ; < = > ^ and |.

请注意， 实体转码 是在URL属性值上是无用的。

参考 ESAPI reference implementation ，查阅URL转义和反转义

String safe = ESAPI.encoder().encodeForURL( request.getParameter( "input" ) );

规则#6 使用专门的库清理掉HTML标签

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 on OWASP Java HTML Sanitizer policy construction, see http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html

规则#7 防御DOM Based XSS攻击

参考 OWASP article on DOM based XSS Prevention Cheat Sheet.

额外规则#1 使用HTTPOnly cookie标识

预防所有的XSS攻击是非常困难的，如你所看。为了减轻这个危害造成的后果，

OWASP推荐将会话cookie 和 任何不用脚本访问的cookie设置为 HTTPOnly标识。

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

额外规则#2 执行内容安全策略

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

XSS防御规则总结

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>
String Safe HTML Attributes <input type="text" name="fname" value="UNTRUSTED DATA">
  • Aggressive HTML Entity Encoding
  • Only place 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>
String Untrusted URL in a SRC or HREF attribute <a href="UNTRUSTED URL">clickme</a>
<iframe src="UNTRUSTED URL" />
String CSS Value <div style="width: UNTRUSTED DATA;">Selection</div>
String JavaScript Variable <script>var currentValue=‘UNTRUSTED DATA‘;</script>
<script>someFunction(‘UNTRUSTED DATA‘);</script>
  • Ensure JavaScript variables are quoted
  • JavaScript Hex Encoding
  • JavaScript Unicode Encoding
  • Avoid backslash encoding (\" or \‘ or \\)
HTML HTML Body <div>UNTRUSTED HTML</div>
String DOM XSS <script>document.write("UNTRUSTED INPUT: " + document.location.hash);<script/>

Safe HTML Attributes include: align, alink, alt,
bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan,
coords, dir, face, height, hspace, ismap, lang, marginheight,
marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev,
rows, rowspan, scrolling, shape, span, summary, tabindex, title,
usemap, valign, value, vlink, vspace, width

输出转码规则总结

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where 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 '
Convert / to /
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 be 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 two character escape
can cause problems if the next character continues the escape sequence.
There are two solutions (a) Add a space after the CSS escape (will be
ignored by the CSS parser) (b) use the full amount of 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 that this article was created to help you avoid:

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

How to Review Code for Cross-site scripting Vulnerabilities

How to Test for Cross-site scripting Vulnerabilities

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)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets

时间： 2024-10-26 05:33:51

XSS (Cross Site Scripting) Prevention Cheat Sheet(XSS防护检查单)的相关文章

防止恶意代码注入XSS(cross site scripting)

Login.PHP页面 <!DOCTYPE html> <html> <head> <title>登录页面</title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> </head> <body> <form action="LoginController.php&

XSS 跨站脚本攻击(Cross Site Scripting)

xss表示Cross Site Scripting(跨站脚本攻击),它与SQL注入攻击类似,SQL注入攻击中以SQL语句作为用户输入,从而达到查询/修改/删除数据的目的,而在xss攻击中,通过插入恶意脚本,实现对用户游览器的控制. xss攻击可以分成两种类型: 非持久型攻击 持久型攻击 下面我们通过具体例子,了解两种类型xss攻击. 1.非持久型xss攻击 顾名思义,非持久型xss攻击是一次性的,仅对当次的页面访问产生影响.非持久型xss攻击要求用户访问一个被攻击者篡改后的链接,用户访问该链接时

xss （Cross Site Scripting）跨站脚本攻击

XSS攻击:跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS. XSS攻击分成两类: 一类是来自内部的攻击,主要指的是利用程序自身的漏洞,构造跨站语句,如:dvbbs的showerror.asp存在的跨站漏洞. 另一类则是来自外部的攻击,主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页.如当我们要渗透一个站点,我们自己构造一个有跨站漏洞的网页,然后构

DVWA 黑客攻防实战（十）反射型 XSS 攻击 Reflected Cross Site Scripting

XSS (Cross-site scripting) 攻击,为和 CSS 有所区分,所以叫 XSS.又是一种防不胜防的攻击,应该算是一种 "HTML注入攻击",原本开发者想的是显示数据,然而攻击者输入却是有破坏性的代码,而且能被解析执行.Symantec在2007年报告更是指出跨站脚本漏洞大概占所有网站漏洞的84%. XSS 大致分成三种类型(白帽子说安全): 反射型,就是本文的内容. 存储型,在这篇文章会介绍. DOM 型,如果用是否会存储在服务器上区分的话,DOM型也是反射型.但比

DOM based XSS Prevention Cheat Sheet(DOM Based XSS防御检查单)

本文为翻译版本,原文请查看 https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet 介绍 谈到XSS攻击,有三种公认的形式,Stored. Reflected 和 DOM Based XSS. XSS Prevention Cheatsheet可以有效地解决 Stored. Reflected XSS攻击, 本检查单解决了 DOM Based XSS攻击,是 XSS Prevention Cheatsheet 的延

RailsCase27 Cross Site Scripting 跨站点脚本攻击

跨站点脚本是开发过程中经常需要考虑的安全问题.此种情形发生在允许用户直接输入html.javascript脚本时.在下述的website中,我们并没有过滤输入的内容,导致一些安全漏洞. 如果在输入框中输入由<script>包围的内容,当页面被加载的时候,脚本将被执行,每次均将在前端展示.例如,如果输入<script>alert('hello')</script>并保存,每次浏览此页面时,都将看到alert的窗口. 嵌入页面的javascript脚本如下: termina

XSS Filter Evasion Cheat Sheet 中文版【转】

译者注: 翻译本文的最初原因是当我自己看到这篇文章后,觉得它是非常的价值.但是这么著名的一个备忘录却一直没有人把它翻译成中文版.很多人仅仅是简单的把文中的各种代码复制下来,然后看起来很刁的发在各种论坛上,不过你要真去认真研读这些代码,就会完全不知所云了.原因是这篇文章最精华的部分是代码的解释而非代码本身. 一方面为了自己学习,一方面也想让更多国内的xss爱好者去更方便的阅读本文.所以虽然我本身英语很烂,xss技术也很烂,但还是去翻译了这篇文章.当然这也导致最后翻译出来的文章晦涩难懂.不知所云.这

XSS Filter Evasion Cheat Sheet 中文版

前言 译者注: 翻译本文的最初原因是当我自己看到这篇文章后,觉得它是非常有价值.但是这么著名的一个备忘录却一直没有人把它翻译成中文版.很多人仅仅是简单的把文中的 各种代码复制下来,然后看起来很刁的发在各种论坛上,不过你要真去认真研读这些代码,就会完全不知所云了.原因是这篇文章最精华的部分是代码的解释而非代 码本身. 一方面为了自己学习,一方面也想让更多国内的xss爱好者去更方便的阅读本文.所以虽然我本身英语很烂,xss技术也很烂,但还是去翻译了这篇文 章.当然这也导致最后翻译出来的文章晦涩难懂.

MySQL SQL Injection Cheat Sheet

MySQL SQL Injection Cheat Sheet Some useful syntax reminders for SQL Injection into MySQL databases- This post is part of a series of SQL Injection Cheat Sheets.  In this series, I've endevoured to tabulate the data to make it easier to read and to u