网络安全攻防：Web安全之URL结构

本文针对URL（Uniform Resource Locator）简单介绍URL的结构和URL的编码与解码等问题。为什么需要对 URL进行编码，对其编码的好处体现在哪里？首先，URL是统一资源标识，通常所说的URL只是URI的一部分。典型的URL的格式如图1所示。

图1 URL格式

而下面所提到的URL编码，实际也应该指的是URI编码。

需要进行编码的部分通常来说是不方便传输或会造成歧义的。原因还有很多，对于URL来说，需要编码是因为 URL中的某些字符会造成歧义。例如，在传输的过程中，通常会使用键值对的方式，username=12345；这种方式对于人而言很好理解，这是一个赋值的过程，而接收URL的服务器却不知道“=”这个字符是字符串数据的一部分还是赋值的需要，所以这里的字符在传输过程中是需要进行编码的。

又例如，URL的编码格式采用的是ASCII码，而不是Unicode，这也就是说URL中不能包含任何非ASCII字符，如中文。否则，如果客户端浏览器和服务端浏览器支持的字符集不同，中文可能会造成问题。

所以，URL编码的原则是使用安全字符去表示那些不安全的字符，如百分号编码。

1. 百分号编码

在介绍百分号编码前，还要了解URL需要对哪些字符进行编码。

RFC3986文档规定，URL中只允许包含英文字母（a～z、A～Z）、数字（0～9）、“-”“_”“.”“～” 4个特殊字符以及所有保留字符。

所谓的保留字符就是划分URL的，分隔不同组件的字符。

RFC3986中指定了以下字符为保留字符，如图2所示。

图2 RFC3986保留字符

百分号编码的编码方式非常简单，使用百分号（%）加上两个字符（0123456789ABCDEF），表示为一个字节的十六进制的形式。URL编码默认使用的字符集是ASCII码。例如，井号（#）对应的十六进制是0x23，所以它的URL编码就为%23。对于非ASCII字符，需要使用ASCII字符集的超集进行编码得到相应的字节，然后对每个字节执行百分号编码。

2. URL解析

在传输前，浏览器会对 URL 进行编码。接收 URL 的服务器主要负责对接收到的URL进行解析。URL的使用过程当中，由于互联网上的每个网页大多会引用与它同服务器甚至是同级目录下的文件，就会使用到相对URL的概念。在介绍URL编码时，展示的是绝对URL，这就相当于电脑中的相对路径与绝对路径的区别。所以在解析的时候，服务器需要区分相对URL与绝对URL。

按照规范里的说法，要区分两者非常简单。如果 URL 字符串不是一个有效的协议名，后面跟的不是冒号（:）或双斜杠（//），那么它就是一个需要被引用的相对URL。其实在实际应用中，对于相对 URL的解析是有规范的，因为不同浏览器的具体实现千差万别，有效协议名称的字符集也各有不同，还有各种替代双斜杠（//）分隔符的方法，因此，接下来会对相对URL的解析进行一个归类。

（1）有协议名称，但没有授权信息（http:abc.txt）。这是一个比较有名的漏洞，它的产生是由RFC3986规范疏忽所致。在规范中将这些地址描述为无效的绝对地址，但在提供的解析算法中又将这种地址的解析搞错了。所以这种形式的URL，在执行过程中会被理解为相对地址来进行处理。例如，在某些情况下，http:abc.txt会被理解为相对地址，而https:example.com会被解释为绝对地址。

（2）没有协议名，但有授权信息（//example.com）。这种写法在规范中给出了较为完整的处理。面对这种URL，浏览器会自动补全该URL。

（3）没有协议名，没有授权信息，但有路径（../robots.txt）。这是一种比较常见的用法，协议和授权信息都从引用URL里复制过来，然后将这个相对地址进行补全。

（4）没有协议名，没有授权信息，没有路径，但有查询的字符串（?username=abc）。在这种情况下，协议、授权信息、路径全都会原封不动地从原引用 URL复制过来。查询字符串和字段ID则来自于相对URL。

（5）只有片段 ID（#bunnies）。这种方式也是如此，其他部分全部原封不动地从原引用URL复制，只替换字段ID的部分。