HTML 的纷争

HTML 语言的混乱主要源于四种主要解析引擎各自为政，IE 的Trident引擎，Firefox 的Gecko ,Safari 和Chrome 的Webkit,Opera 的Presto.

HTML 文档的基本概念

语法

HTML 是标签组成的层级结构，文本穿插其中，而主要是使用无个字符进行约束和限制，左右尖括号，单引号，双引号，&，所以说，HTML 里会有一些针对这些字符的规则：

• HTML 文档的绝大部分区域不应该出现单个「&」符号。
• HTML 标签内部不应该出现左右尖括号。
• 文本节点的左尖括号是危险的。
• 标签中出现引号字符串可能导致意想不到的效果。

以上几条规劝，实际上就是在告诫这样书写的代码，随时会被攻击者抓住，利用代码的缺陷，构造XSS 或者是SQL注入。

文档解析模式

对于传统的HTML，解析器会修复大部分语法上的不合规，同时不区分大小写，参数值不一定要用括号括起来，某些标签可以隐式闭合，而对于XML 来说，标签必须严格匹配，区分大小写，可以整合其他兼容格式内容。

值得一提的是，对于HTML ，碰到某些标签后，会落入特殊模式，直到出现特定的终止字符才会退出状态。如style, script, textarea, xmp 直到出现反斜杠匹配，才会退出。

而对于XML，禁止出现单个「<」和「&」，还有一个特殊的语法，只要一”<![CDATA[“字符串开头，以”]])”结束的，中间短路可以封装含有人以标签的任意原始文本数据。

语义之争：Tim Berners-Lee 的语义网梦想，这里还是比较遥远，不做进一步探讨。

HTML 解析器的行为

对于XML 来说，不需要担心，因为解析器的错误几乎零容忍。但是，对于HTML 来说，简直就是灾难，为了最大程度的解析，HTML 会以各种让人摸不着头脑的大胆的方式猜测网页作者的用途。以下边这个标签为例：

先不考虑它没有闭合仍然正常被解析这件事，看各家解析器做出的各种支持：

• IE 浏览器允许吧空字节NUL（0x00） 插入到1位置
• 2，4的空白位置可以使用垂直制表符(0x0b)或者进纸换页符(0x0c)替换，令人惊奇的是FireFox 允许在2 用单个普通的正斜杠代替。
• 3，曾经WebKit 甚至允许此处有正斜杠使用。
• 位置5，在IE还能接受反引号。
• 被引号括起来的参数，后边实际上隐式的跟着一个空格符，所以位置6空格可以去掉。

一个常见的攻击手段就是xss，此处借助title,我们将 hello world 替换成 hello world” onerror=”alert(1) 于是，对于原标签就变成了：

1

<img src=image.jpg tile="hello world"onerror="alert(1)" class=example>

很自然的一个脚本被我们植入进去了，一个xss 就被触发了。

多重标签的交互

在不正常的HTML 里，还会出现多个HTML 标签堆叠在一起，看起来就让人头疼，而浏览器在解析的时候，也会有区别，比如:

1

<i <b>

大多数浏览器会先解析成‘< i >’ ，而把< b 视为无效的标签参数。

另外，整个文档结束时候标签未闭合的情况也让人摸不清头脑。比如：

1

<i foo="<b>" [EOF]

大多数浏览器解析为i 的标签，或者是整个忽略掉，但对于IE 和 Opera 却从后往前处理，把这一串理解成 b 的标签。

所以假如攻击者，可以阶段加载的页面，就可以通过构造手段，让浏览器解析成完全不同的内容。

HTML 实体编码

（由于MarkDown语言里，自动把这些编码识别出来了，包括尖括号，只好中间加空格或这种方式来书写。）

hTML 的实体编码格式是以&开头，以分号结尾，在HTML 规范里，散步着无数这样的命名实体，比如& lt; 插入左尖括号，& gt;用于插入右尖括号，& amp; 替换 &符号自身。& rarr; 代表一个Unicode箭头等等。

除了命名实体，还可以插入任意十进制ASCII 或者 Unicode 字符编码，样式是 &#数字；
例如 &# 60; 被识别成左尖括号，&# 62; 别识别为右尖括号。而十六进制的标记符在这在编码前边加一个x,所以 &# x3c; 仍然是一个左尖括号。

对于HTML 来说，解析器能识别在文本节点和参数值里边的实体编码，在创建文档树的时候，透明的对这些编码进行解码。

但是有一点疑惑的是，在识别和解析HTML 实体任务重，有一些奇怪的解析，比如传统解析中，只要实体名称后边跟着的字符不是字母数字，即使是少了分号，实体名还是被接受了。对于数字型的实体，后边可以跟任意多个0，导致一个超长的数字串，会造成出错。

HTTP/HTML 交互语义

一般来说，我们会在HTTP 的头域指定内容的一些信息，比如Content-Type, Content-Disposition, Transfer-Encoding等等，然而考虑如果我们不适用HTTP 传输HTML，甚至是直接从本地加载HTML，就不能依靠HTTP 的头域来确定编码等信息了。如果缺了像 MIME type 或者字符集这样关键参数，就会破事浏览器随意处置文档的编码解析问题。

解决办法就是文档开头声明< meta http-equiv=…> 指令进行编码设定，一个典型的指定是这样的：

1

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

如果多个http-equiv冲突，或者从服务器端返回HTTP 头域有冲突的话，浏览器表现就会很不一致，一般优先支持hTTP 响应头，然后支持第一个出现的charset。

超链接与内容包含

这一块是XSS 的重灾区。

一个单纯的HTML 链接写法是这样的：

1

<a href="http://www.example.com/">click me!</a>

对于这个超链接，它支持指向浏览器支持的所有协议，包括伪URL，如data: javascript:。

同时，该语法可选的target参数有四种，_blank总是打开新窗口；_parent 转到包含发出当前链接文档的上一级视图；_top 转到浏览器最顶级窗口。_self 和没有设置这个值一样。

表单和表单触发的请求

XSS 重灾区。

一个典型的表单写法如下：

1
2
3
4
5
6

<form method=GET action="/process_form.cgi">
名字：<input type=text name=given>
姓氏：<input type=text name=family>
...
<input type=submit value="完成后提交">
</form>

值得注意的是，form 彼此不能嵌套，如果嵌套了，只有最外层的有效。

如果method 为GET，那么包含的字段名称和他们的值，会以百分号编码机制转义，但其中空格(0x20) 会被以加号代替而非%20,而所有的加号被编码成%2b 。经过编码的「名称=值」数据对用& 连接付分割，组成完整的字符串。

如果method 是POST，分几种情况：

• 默认情况下，application/x-www-form-urlencoded 编码方式，信息组成方式与GET 方式相同，不同的是数据会放在请求头的数据体部分提交，目标URL 查询字符串和其他部分保持不变。潜在的问题，如果查询字符串和POST 数据体参数相同，冲突，可能会造成HTTP 参数污染
• 额外的把form 标签中的编码设置为enctype = “text/plain”。而采用这种做法，字段的名称和值不会以百分号编码方式进行编码，某些浏览器可能会把空格替换成加号，而原来用于分割的& 以换行符替换。因此，这样格式的数据，无法明确的对赎金进行解析，因为无法完全区分换行符和等号是表单带进来的，还是浏览器加入的。
• entype = “multipart/form-data”，通过表单提交用户选择的文件时候，要用这种模式，会产生一系列较短的MIME 消息，对应于提交的每个字段。然后每个字段会有一个由哭护短选择的特定符号分割。

Frame 框架

其作用是使HTML 文档内嵌和显示另一个页面中，有独立的文档视图，甚至独立的JS 环境。对于src 值的限定，与其他链接的规则基本相同， 所以 iframe 也是一个安全隐含。

其他特定的内容

包括图片，层级样式表，客户端脚本，插件内容等等，这些不再赘述，他们都有XSS 的风险。

安全工程

• 良好的规范，良好的规范，良好的规范，毫无疑问要确保输出统一的、有效的、浏览器支持的Content-type 响应头和 charset 字符集信息，以免文档不能按照原有意思解析。
• 文档包括可被控制的信息时，应当充分考虑到漏洞的可能。
  • 针对文本部分里用户提供内容：应当以实体编码方式处理左右尖括号和& ， 以及其他的各种ASCII等编码问题。同时，某些Unicode 元字符 U+202E 可能会改变之后文本的显示方向和顺序，是不是想起了微信。
  • 针对style 和 on* 标签参数，要做多重编码转义处理，但这种处理往往又有可能出错，所以处处小心。
  • 其他的HTML 参数值，对攻击者能够控制的输入，总是用引号来括起来，对左右尖括号和& 以及任何单独出现的引号都要进行实体编码。同时，不要对URL 或其他参数有问题的值做黑名单验证，反而会造成脚本执行漏洞。
  • 特殊的解析模式下，如script, style 区块里的内容，仍然是仔细处理引号字符串，左右尖括号，所有非打印字符都应做好合适的转义处理。

HTML 部分写完，但是要想完全搞清楚HTML 编码部分的问题，简直是一件不可能完成的任务，曾经有本书叫《Web Application Obfuscation》，它企图创建出能拦截所有已知的危险模式的过滤器，同时又不会影响到其他段落的正常功能，而实际上，这是不可能完成的任务。

一个良好的方法是用一个解析器，把输入的文档翻译成放在内存里的层级文档树，然后去除掉那些无法识别的参数和标签，和所有不需要的标签、参数、参数值。然后在对文档树进行良好的排序和转义，这样看起来要方便和清晰许多。

另外，HTML 中存在问题，造成最大的影响就是XSS 和CSRF 这两个攻击手段，攻击者会绞尽脑汁的绕过开发者设置的层层障碍，他们的最终目的无论如何，都是试图通过各种混淆的代码，让解析器理解成其他意思，达成攻击效果。而XSS 的三种攻击模式，反射型，储存型，DOM 型，都是在这些修修补补的篱笆上找一个足以穿越过去的漏洞。

在配合上HTTP 的问题，可以创造一切可能，对于XSS 的世界，脑洞有多大，可能有多大。