《防御xss的七条原则》由会员分享，可在线阅读，更多相关《防御xss的七条原则（10页珍藏版）》请在金锄头文库上搜索。
1、防御XSS的七条原则,前言,本文将会着重介绍防御XSS攻击的一些原则，需要读者对于XSS有所了解，至少知道XSS漏洞的基本原理，如果您对此不是特别清楚，请参考这两篇文章：Stored and Reflected XSS AttackDOM Based XSS 攻击者可以利用XSS漏洞向用户发送攻击脚本，而用户的浏览器因为没有办法知道这段脚本是不可信的，所以依然会执行它。对于浏览器而言，它认为这段脚本是来自可以信任的服务器的，所以脚本可以光明正大地访问Cookie，或者保存在浏览器里被当前网站所用的敏感信息，甚至可以知道用户电脑安装了哪些软件。这些脚本还可以改写HTML页面，进行钓鱼攻击。 虽然
2、产生XSS漏洞的原因各种各样，对于漏洞的利用也是花样百出，但是如果我们遵循本文提到防御原则，我们依然可以做到防止XSS攻击的发生。 有人可能会问，防御XSS的核心不就是在输出不可信数据的时候进行编码，而现如今流行的Web框架（比如Rails）大多都在默认情况下就对不可信数据进行了HTML编码，帮我们做了防御，还用得着我们自己再花时间研究如何防御XSS吗？答案是肯定的，对于将要放置到HTML页面body里的不可信数据，进行HTML编码已经足够防御XSS攻击了，甚至将HTML编码后的数据放到HTML标签（TAG）的属性（attribute）里也不会产生XSS漏洞（但前提是这些属性都正确使用了引号）
3、，但是，如果你将HTML编码后的数据放到了标签里的任何地方，甚至是HTML标签的事件处理属性里（如onmouseover），又或者是放到了CSS、URL里，XSS攻击依然会发生，在这种情况下，HTML编码不起作用了。所以就算你到处使用了HTML编码，XSS漏洞依然可能存在。下面这几条规则就将告诉你，如何在正确的地方使用正确的编码来消除XSS漏洞。,原则1：不要在页面中插入任何不可信数据，除非这些数已经据根据下面几个原则进行了编码,第一条原则其实是“Secure By Default”原则：不要往HTML页面中插入任何不可信数据，除非这些数据已经根据下面几条原则进行了编码。 之所以有这样一条原则
4、存在，是因为HTML里有太多的地方容易形成XSS漏洞，而且形成漏洞的原因又有差别，比如有些漏洞发生在HTML标签里，有些发生在HTML标签的属性里，还有的发生在页面的里，甚至有些还出现在CSS里，再加上不同的浏览器对页面的解析或多或少有些不同，使得有些漏洞只在特定浏览器里才会产生。如果想要通过XSS过滤器（XSS Filter）对不可信数据进行转义或替换，那么XSS过滤器的过滤规则将会变得异常复杂，难以维护而且会有被绕过的风险。 所以实在想不出有什么理由要直接往HTML页面里插入不可信数据，就算是有XSS过滤器帮你做过滤，产生XSS漏洞的风险还是很高 不要在这里直接插入不可信数据直接插入到SC
5、RIPT标签里 插入到HTML注释里 插入到HTML标签的属性名里 插入到HTML标签的属性值里 作为HTML标签的名字 不要在这里直接插入不可信数据 直接插入到CSS里最重要的是，千万不要引入任何不可信的第三方JavaScript到页面里，一旦引入了，这些脚本就能够操纵你的HTML页面，窃取敏感信息或者发起钓鱼攻击等等。,原则2：在将不可信数据插入到HTML标签之间时，对这些数据进行HTML Entity编码,在这里相当强调是往HTML标签之间插入不可信数据，以区别于往HTML标签属性部分插入不可信数据，因为这两者需要进行不同类型的编码。当你确实需要往HTML标签之间插入不可信数据的时候，首
6、先要做的就是对不可信数据进行HTML Entity编码。比如，我们经常需要往DIV，P，TD这些标签里放入一些用户提交的数据，这些数据是不可信的，需要对它们进行HTML Entity编码。很多Web框架都提供了HTML Entity编码的函数，我们只需要调用这些函数就好，而有些Web框架似乎更“智能”，比如Rails，它能在默认情况下对所有插入到HTML页面的数据进行HTML Entity编码，尽管不能完全防御XSS，但着实减轻了开发人员的负担。 插入不可信数据前，对其进行HTML Entity编码插入不可信数据前，对其进行HTML Entity编码插入不可信数据前，对其进行HTML Enti
7、ty编码 以此类推，往其他HTML标签之间插入不可信数据前，对其进行HTML Entity编码编码规则 那么HTML Entity编码具体应该做哪些事情呢？它需要对下面这6个特殊字符进行编码： ,原则3：在将不可信数据插入到HTML属性里时，对这些数据进行HTML属性编码,这条原则是指，当你要往HTML属性（例如width、name、value属性）的值部分(data value)插入不可信数据的时候，应该对数据进行HTML属性编码。不过需要注意的是，当要往HTML标签的事件处理属性（例如onmouseover）里插入数据的时候，本条原则不适用，应该用下面介绍的原则4对其进行JavaScrip
8、t编码。 属性值部分没有使用引号，不推荐 属性值部分使用了单引号 属性值部分使用了双引号编码规则 除了阿拉伯数字和字母，对其他所有的字符进行编码，只要该字符的ASCII码小于256。编码后输出的格式为 ,原则4：在将不可信数据插入到SCRIPT里时，对这些数据进行SCRIPT编码,这条原则主要针对动态生成的JavaScript代码，这包括脚本部分以及HTML标签的事件处理属性（Event Handler，如onmouseover, onload等）。在往JavaScript代码里插入数据的时候，只有一种情况是安全的，那就是对不可信数据进行JavaScript编码，并且只把这些数据放到使用引号包
9、围起来的值部分（data value）之中，例如：var message = “”;除此之外，往JavaScript代码里其他任何地方插入不可信数据都是相当危险的，攻击者可以很容易地插入攻击代码。 alert(插入不可信数据前，进行JavaScript编码)值部分使用了单引号 x = “插入不可信数据前，进行JavaScript编码” 值部分使用了双引号 值部分使用了引号，且事件处理属性的值部分也使用了引号 特别需要注意的是，在XSS防御中，有些JavaScript函数是极度危险的，就算对不可信数据进行JavaScript编码，也依然会产生XSS漏洞，例如： window.setInterva
10、l(就算对不可信数据进行了JavaScript编码，这里依然会有XSS漏洞); 编码规则 除了阿拉伯数字和字母，对其他所有的字符进行编码，只要该字符的ASCII码小于256。编码后输出的格式为 xHH （以 x 开头，HH则是指该字符对应的十六进制数字） 在对不可信数据做编码的时候，千万不能图方便使用反斜杠（ ）对特殊字符进行简单转义，比如将双引号 ” 转义成 ” ，这样做是不可靠的，因为浏览器在对页面做解析的时候，会先进行HTML解析，然后才是JavaScript解析，所以双引号很可能会被当做HTML字符进行HTML解析，这时双引号就可以突破代码的值部分，使得攻击者可以继续进行XSS攻击。例
11、如： 假设代码片段如下：var message = ” $VAR “; 攻击者输入的内容为： ”; alert(xss);/如果只是对双引号进行简单转义，将其替换成 ” 的话，攻击者输入的内容在最终的页面上会变成：var message = ” ”; alert(xss);/ “; 浏览器在解析的时候，会认为反斜杠后面的那个双引号和第一个双引号相匹配，继而认为后续的alert(xss)是正常的JavaScript脚本，因此允许执行。 可以使用ESAPI提供的函数进行JavaScript编码： String encodedContent = ESAPI.encoder().encodeForJa
12、vaScript(request.getParameter(“input”);,原则5：在将不可信数据插入到Style属性里时，对这些数据进行CSS编码,当需要往Stylesheet，Style标签或者Style属性里插入不可信数据的时候，需要对这些数据进行CSS编码。传统印象里CSS不过是负责页面样式的，但是实际上它比我们想象的要强大许多，而且还可以用来进行各种攻击。因此，不要对CSS里存放不可信数据掉以轻心，应该只允许把不可信数据放入到CSS属性的值部分，并进行适当的编码。除此以外，最好不要把不可信数据放到一些复杂属性里，比如url, behavior等，只能被IE认识的Expressio
13、n属性允许执行JavaScript脚本，因此也不推荐把不可信数据放到这里。 selector property : 插入不可信数据前，进行CSS编码 selector property : ” 插入不可信数据前，进行CSS编码 “ 编码规则 除了阿拉伯数字和字母，对其他所有的字符进行编码，只要该字符的ASCII码小于256。编码后输出的格式为 HH （以 开头，HH则是指该字符对应的十六进制数字） 同原则2，原则3，在对不可信数据进行编码的时候，切忌投机取巧对双引号等特殊字符进行简单转义，攻击者可以想办法绕开这类限制。 可以使用ESAPI提供的函数进行CSS编码： String encoded
14、Content = ESAPI.encoder().encodeForCSS(request.getParameter(“input”);,原则6：在将不可信数据插入到HTML URL里时，对这些数据进行URL编码,当需要往HTML页面中的URL里插入不可信数据的时候，需要对其进行URL编码，如下：Link Content 编码规则 除了阿拉伯数字和字母，对其他所有的字符进行编码，只要该字符的ASCII码小于256。编码后输出的格式为 %HH （以 % 开头，HH则是指该字符对应的十六进制数字） 在对URL进行编码的时候，有两点是需要特别注意的： 1) URL属性应该使用引号将值部分包围起来，
15、否则攻击者可以很容易突破当前属性区域，插入后续攻击代码 2) 不要对整个URL进行编码，因为不可信数据可能会被插入到href, src或者其他以URL为基础的属性里，这时需要对数据的起始部分的协议字段进行验证，否则攻击者可以改变URL的协议，例如从HTTP协议改为DATA伪协议，或者javascript伪协议。 可以使用ESAPI提供的函数进行URL编码： String encodedContent = ESAPI.encoder().encodeForURL(request.getParameter(“input”);ESAPI还提供了一些用于检测不可信数据的函数，在这里我们可以使用其来检测
16、不可信数据是否真的是一个URL： String userProvidedURL = request.getParameter(“userProvidedURL”);boolean isValidURL = ESAPI.validator().isValidInput(“URLContext”, userProvidedURL, “URL”, 255, false); if (isValidURL) ” ,原则7：使用富文本时，使用XSS规则引擎进行编码过滤,Web应用一般都会提供用户输入富文本信息的功能，比如BBS发帖，写博客文章等，用户提交的富文本信息里往往包含了HTML标签，甚至是JavaScript脚本，如果不对其进行适当的编码过滤的话，则会形成XSS漏洞。但我们又不能因为害怕产生XSS漏洞，所以就不允许用户输入富文本，这样对用户体验伤害很大。 针对富文本的特殊性，我们可以使用XSS规则引擎对用户输入进行编码过滤，只允许用户输入安全的HTML标签，如, , 等，对其他数据进行HTML编码。需要注意的是，经过规则引擎编码过滤后的内容只能放在, 等安全的HTML标签里，不要放到HTML标签的属性值里，更不要放到HTML事件处理属性里，或者放到标签里。 推荐XSS规则过滤引擎：OWASP AntiSamp或者Java HTML Sanitizer,
