XSS解决方案：浏览器是如是解码的

1、我本人一直关注“知识”与“知识运用”之间的区别，我曾经举过一个例子说： “知识”与“知识运用”就如牛郎星与织女星，感觉二者之间似乎关系密切，实则相隔甚远!我在初学平面几何时，经常会这么想： 两条线平行则永远不会相交，这不是废话吗！三角形两边之和当然大于第三边了！在实际运用当中，我经常是需要用它的时候想不起来或者用错了它们。我的文章输入验证可避免一半以上的应用安全攻击 ，对于此文我相信是it 业界的人都能看明白，但是对于一个企业来说，它的价值万金，有多少人可以体味呢 ?对于 xss 问题的系统性解决方案上也是一样的。许多公司已经 90%以上的程度解决了 xss 问题，但是依然存在那10%的风险，

2、风险在哪里，我想我会一步一步给大家分享清楚。 xss 问题是全球性普遍性问题， 没有深度的探索就不可能有彻底的解决方案，没有灵丹妙药，只有正确的方法！好，进入正题。基于http协议的b/s（browser/server架构的 web应用程序，有它的特殊性，它结构松散、 多标签语言相互嵌入以及服务端与客户端使用了相互关联实现上却完全不同等等复杂的技术，以至于给基于 http 协议的 web 应用程序埋下了诸多潜在的安全问题， xss 问题就是其中之一。我们使用c/c+/javascript,大家都清楚，如果我想在字符串当中表达字符【” 】 ， 很自然的就会想到转义【 ”】 ， 想在字符串当中表达

3、【 】 ， 就得使用转义（与本文中所说“编码”概念相同）形式【】 ，在 html 文档当中也是这样，但是大家有没有想过这几个问题：1. 这个转义后的字符串是为谁而转义的 ?2. 这个转义后的字符串是何时被还原成转义前的字符串的 ?3. 有没有可能还原之后的字符被重新放回到代码中而忽略了转义?答案：1. 为解释器 （或编译器，为了简单，后面只称解释器）而转义，字符串被解释后在内存当中的字符串等同于转义前字符串2. 通常解释器是在读取语言（c/c+/javascript）字符串后进行本地语言转 换前进行还原的3. 有， 在基于 html 架构的前端（浏览器端）应用程序，尤为常见。 比如 : var

4、mystring二，如果被document.whte（mystring）重新写至u dom里，结果是什么呢？ 或者也可能会直接赋值给某一html 节点的 innerhtml/outerhtml 属性， 这里的问题就复杂了， 二次赋值之后， 你的程序没那么聪明， 它不会主动替你转义一下再赋值， 你可能会说： 这不就是 dom base xss 吗? 你想的简单了， 对于我来说是dom based反射式的还是存储式的，这种分类意义不大，解决方案都是一样， 这就是高级别抽象后的解决方案的统一。 这个问题较复杂， 我们循序渐进的来了解它，您先知道有这么回事儿。有心的读者可能会问：c/c+/java会有

5、这种情形吗 ? 答案是：当然有，有一些软件为了兼容性等诸多因素考虑，会在编译时依据条件不同动态生成新的代码然后再进行编译，此时你该如何是好 ?这不是本文讨论的重点，为了叙述的完整性， 提一下有这么回事儿就行。 本文的重点是web 应用当中的xss 问题。铺垫的差不多了，我们来一起看一段以下的 html 的 document: jiayzhans item【说明】带有字符串【jiayzhan】的一整串，您需要将它们理解为类似于这 样的jsp代码：下面一步一步来说浏览器是如何解码（反转义）的，我就用字符串本身作为位置标识来解释：1. 位置：jiayzhan s item, 浏览器在解析这个位置的字

6、符串时，无论如何，会对其进行一次html 解码， （html 编码、解码，请参考）2. 位置： s onclick， 无论如何， 浏览器会对其进行： 1） 先做 html 解码2）再做js解码3. 位置 : ，无论如何，浏览器会对其进行： url 解码4. 位置： jiayzhan s url， 无论如何，浏览器会对此位置字符串进行： 1） 先javascript解码（js编解码请参考）2）后url解码以上只是一维与二维组合的情形， 实际当中还会有三维以上的解码组合， 特别是大量使用 web2.0技术的网站。您理解了吗？如果您真的理解了，请分析一下

7、以下代码段中的变量，浏览器如何做解码?如果你真的理解了浏览器的解码过程，你何尝不知道你在解决xss 问题时的编码过程? 请在评论中回复，我会及时与您讨论：）” click jiayzhan说明：backtohome是一个 javascript 函数在这里先不说它的解码过程， 提示一下它是一个三维解码过程， 供读者讨论写到这里， 我想点睛一下我上文所述的” 许多公司已经90%以上的程度解决了 xss 问题”而不是100%的原因了。本id 曾给某一知名公司报了一个xss 问题，其存在xss 问题的地方因为是一个三维的解码语法环境，应用安全与开发人员许久也没有找到合理的解决方案，最终此公司删除了那个有xss 问题的功能点。不点名了，如果有幸遇到此公司的应用安全人员，这篇文章读明白了，问题应该就好解决了。 还是那句话： 知识与知识运用相隔甚远， 我无法保证您可以正确运用它。既然知道浏览器是如何解码的了，我们该如何做编码的事应该水到渠成了，不过依我的经验看， 许多专业做xss 问题 fix 的解决方案的安全人员依然存在难以转过这个弯的情况。 下篇文章我将举几个具体的例子来说明如何利用解码原理用来彻底解决xss 问题的编码问题，以及在涉及到多重解码的环境如果考虑维数不足所带来的安