文档介绍：我的文章《输入验证可避免一半以上的应用安全攻击》,对于此文我相信是IT业界的人都能看明白,但是对于一个企业来说,它的价值万金,有多少人可以体味呢? 对于XSS问题的系统性解决方案上也是一样的。许多公司已经90%以上的程度解决了XSS问题,但是依然存在那10%的风险,风险在哪里,我想我会一步一步给大家分享清楚。XSS问题是全球性普遍性问题,没有深度的探索就不可能有彻底的解决方案,没有灵丹妙药,只有正确的方法! 好,进入正题。基于HTTP协议的B/S(browser/server)架构的Web应用程序,有它的特殊性,它结构松散、多标签语言相互嵌入以及服务端与客户端使用了相互关联实现上却完全不同等等复杂的技术,以至于给基于HTTP协议的Web应用程序埋下了诸多潜在的安全问题,XSS问题就是其中之一。我们使用C/C++/Javascript,大家都清楚,如果我想在字符串当中表达字符【”】,很自然的就会想到转义【\”】,想在字符串当中表达【\】,就得使用转义(与本文中所说“编码”概念相同)形式【\\】,在HTML文档当中也是这样,但是大家有没有想过这几个问题: ? ? ? 答案: (或编译器,为了简单,后面只称解释器)而转义,字符串被解释后在内存当中的字符串等同于转义前字符串 (C/C++/Javascript…)字符串后进行本地语言转换前进行还原的 ,在基于HTML架构的前端(浏览器端)应用程序,尤为常见。比如:varmyString=”,(myString)重新写到DOM里,结果是什么呢?或者也可能会直接赋值给某一HTML节点的innerHTML/outerHTML属性,这里的问题就复杂了,二次赋值之后,你的程序没那么聪明,它不会主动替你转义一下再赋值,你可能会说:这不就是DOMBaseXSS吗?你想的简单了,对于我来说是DOMBased、反射式的还是存储式的,这种分类意义不大,解决方案都是一样,这就是高级别抽象后的解决方案的统一。这个问题较复杂,我们循序渐进的来了解它,您先知道有这么回事儿。有心的读者可能会问:C/C++/Java会有这种情形吗?答案是:当然有,有一些软件为了兼容性等诸多因素考虑,会在编译时依据条件不同动态生成新的代码然后再进行编译,此时你该如何是好?这不是本文讨论的重点,为了叙述的完整性,提一下有这么回事儿就行。本文的重点是Web应用当中的XSS问题。铺垫的差不多了,我们来一起看一段以下的HTML的document: jiayzhan'sitem 【说明】带有字符串【jiayzhan】的一整串,您需要将它们理解为类似于这样的JSP代码: 下面一步一步来说浏览器是如何解码(反转义)的,我就用字符串本身作为位置标识来解释: :jiayzhan’sitem,浏览器在解析这个位置的字符串时,无论如何,会对其进行一次HTML解码,(HTML编码、解码,请参考) :jiayzhan\’sonclick,无论如何,浏览器会对其进行:1)先做HTML解码2)再做JS解码 :何,浏览器会对其进行:URL解码 4