HTTP

HTTP（Hypertext Transfer Protocol，超文本传输协议 ）是在万维网上进行通信时所使用的协议方案。HTTP 有很多应用，但最著名的是用于 Web 浏览器和 Web 服务器之间的双工通信。

每天，都有数以亿万计的 JPEG 图片、HTML 页面、文本文件、MPEG 电影、WAV音频文件、Java 小程序和其他资源在因特网上游弋。HTTP 可以从遍布全世界的Web 服务器上将这些信息块迅速、便捷、可靠地搬移到人们桌面上的 Web 浏览器上去。

HTTP 使用的是可靠的数据传输协议，因此即使数据来自地球的另一端，它也能够确保数据在传输的过程中不会被损坏或产生混乱。

HTTP协议版本

HTTP 协议有好几个版本（0.9/1.0/1.0+/1.1/2.0/3.0）。

有些版本已经被取代或者未推广开来，目前最广泛使用的是HTTP/1.0和HTTP1.1

• HTTP/0.9
  HTTP 的 1991 原型版本称为 HTTP/0.9。这个协议有很多严重的设计缺陷，只应该用于与老客户端的交互。HTTP/0.9 只支持 GET 方法，不支持多媒体内容的MIME 类型、各种 HTTP 首部，或者版本号。HTTP/0.9 定义的初衷是为了获取简单的 HTML 对象，它很快就被HTTP/1.0 取代了。
• HTTP/1.0
  1.0 是第一个得到广泛使用的 HTTP 版本。HTTP/1.0 添加了版本号、各种 HTTP首部、一些额外的方法，以及对多媒体对象的处理。HTTP/1.0 使得包含生动图片的 Web 页面和交互式表格成为可能，而这些页面和表格促使万维网为人们广泛地接受。这个规范从未得到良好地说明。在这个 HTTP 协议的商业演进和学术研究都在快速进行的时代，它集合了一系列的最佳实践。
• HTTP/1.0+
  在 20 世纪 90 年代中叶，很多流行的 Web 客户端和服务器都在飞快地向 HTTP中添加各种特性，以满足快速扩张且在商业上十分成功的万维网的需要。其中很多特性，包括持久的 keep-alive 连接、虚拟主机支持，以及代理连接支持都被加入到 HTTP 之中，并成为非官方的事实标准。这种非正式的 HTTP 扩展版本通常称为 HTTP/1.0+。
• HTTP/1.1
  HTTP/1.1 重点关注的是校正 HTTP 设计中的结构性缺陷，明确语义，引入重要的性能优化措施，并删除一些不好的特性。HTTP/1.1 还包含了对 20 世纪 90 年代末正在发展中的更复杂的 Web 应用程序和部署方式的支持。HTTP/1.1 是当前使用的 HTTP 版本。
• HTTP-NG（又名 HTTP/2.0）
  HTTP-NG 是 HTTP/1.1 后继结构的原型建议，它重点关注的是性能的大幅优化，以及更强大的服务逻辑远程执行框架。HTTP-NG 的研究工作终止于 1998 年，目前还没有任何要用此建议取代 HTTP/1.1 的推广计划。

HTTP与TCP/IP的关系

HTTP 是个应用层协议。HTTP 无需操心网络通信的具体细节；它把联网的细节都交给了通用、可靠的因特网传输协议 TCP/IP。

TCP 提供了：

• 无差错的数据传输；
• 按序传输（数据总是会按照发送的顺序到达）；
• 未分段的数据流（可以在任意时刻以任意尺寸将数据发送出去）。

只要建立了 TCP 连接，客户端和服务器之间的报文交换就不会丢失、不会被破坏，也不会在接收时出现错序了。

用网络术语来说，HTTP 协议位于 TCP 的上层。

Web客户端和服务器

Web 内 容 都 是 存 储 在 Web 服 务 器 上 的。Web 服 务 器 所 使 用 的 是 HTTP 协 议， 因此经常会被称为 HTTP 服务器。这些 HTTP 服务器存储了因特网中的数据，如果HTTP 客户端发出请求的话，它们会提供数据。客户端向服务器发送 HTTP 请求，服务器会在 HTTP 响应中回送所请求的数据

浏 览 一 个 页 面 时， 浏 览 器 会 向 服 务 器发送一条 HTTP 请求。服务器会去寻找所期望的对象（在这个例子中就是 /index.html），如果成功，就将对象、对象类型、对象长度以及其他一些信息放在 HTTP 响应中发送给客户端。

Web资源

Web 服 务 器 是 Web 资 源（Web resource） 的 宿 主。Web 资 源 是 Web 内 容 的 源 头。最简单的 Web 资源就是 Web 服务器文件系统中的静态文件。这些文件可以包含任 意 内 容： 文 本 文 件、HTML 文 件、 微 软 的 Word 文 件、Adobe 的 Acrobat 文 件、JPEG 图片文件、AVI 电影文件，或所有其他你能够想到的格式。

但资源不一定非得是静态文件。资源还可以是根据需要生成内容的软件程序。

URI

每个 Web 服务器资源都有一个名字，这样客户端就可以说明它们感兴趣的资源是什么了。服务器资源名被称为统一资源标识符（Uniform Resource Identifier，URI）。URI 就像因特网上的邮政地址一样，在世界范围内唯一标识并定位信息资源。

这就是http://www.ameng.comWeb服务器上一个图片资源的URI，给定了URI，HTTP协议就可以解析出对象。

URI 有两种形式，分别称为 URL 和 URN。

URL

统一资源定位符（URL）是资源标识符最常见的形式。URL 描述了一台特定服务器上某资源的特定位置。它们可以明确说明如何从一个精确、固定的位置获取资源。如图，URL 说明了协议、服务器和本地资源。

大部分 URL 都遵循一种标准格式，这种格式包含三个部分。

• URL 的第一部分被称为 方案（scheme），说明了访问资源所使用的协议类型。这部分通常就是 HTTP 协议（http://）。
• 第二部分给出了服务器的因特网地址。
• 第三部分给出了资源路径，指定了 Web 服务器上的某个资源。

现在，几乎所有的 URI 都是 URL。

URL语法建立在一个由9部分构成的通用格式上，但几乎没有哪个URL中包含了所有的这些组件。URL最重要的三个部分是方案（scheme）、主机（host）和路径（path）

在Web中，常见的URL除了方案+主机+路径，往往后面还会携带一长串字符。如下图所示

• 协议：http或https（超文本传输协议）
• 域名或IP：www.baidu.com 就是一个域名 域名通过DNS（域名系统）转换为IP地址 www.baidu.com -> 180.101.49.11
• 端口号：端口是网络协议用来提供服务的窗口，服务器默认用80/443端口提供http/https服务
• 路径：用来请求不同的页面
• 查询字符串：查询字符串（URL参数）是指在URL的末尾加上用于向服务器发送信息的字符串（变量）。将？放在URL的末尾，然后再加上参数＝值，想加上多个参数的话，使用&。以这个形式，可以将想要发送给服务器的数据添加到URL中。
• 锚点：锚点就等同于火影中的“飞雷神之术”，使用#内容
  可以快速定位页面中的某个内容

URN

URI 的第二种形式就是统一资源名（URN）。URN 是作为特定内容的唯一名称使用的，与目前的资源所在地无关。使用这些与位置无关的 URN，就可以将资源四处搬移。通过 URN，还可以用同一个名字通过多种网络访问协议来访问资源。

比如，不论因特网标准文档 RFC 2141 位于何处（甚至可以将其复制到多个地方），都可以用下列 URN 来命名它：urn:ietf:rfc:2141

URN 仍然处于试验阶段，还未大范围使用。为了更有效地工作，URN 需要一个支撑架构来解析资源的位置。而此类架构的缺乏也延缓了其被采用的进度。

MIME 类 型

因 特 网 上 有 数 千 种 不 同 的 数 据 类 型，HTTP 仔 细 地 给 每 种 要 通 过 Web 传 输 的 对象 都 打 上 了 名 为 MIME 类 型（MIME type） （Multipurpose Internet Mail Extension，多用途因特网邮件扩展）的 数 据 格 式 标 签。

Web 服务器会为所有 HTTP 对象数据附加一个 MIME 类型。当 Web浏览器从服务器中取回一个对象时，会去查看相关的 MIME 类型，看看它是否知道应该如何处理这个对象。

MIME 类型是一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔。

• HTML 格式的文本文档由 text/html 类型来标记。
• 普通的 ASCII 文本文档由 text/plain 类型来标记。
• JPEG 版本的图片为 image/jpeg 类型。
• GIF 格式的图片为 image/gif 类型。
• Apple 的 QuickTime 电影为 video/quicktime 类型。
• 微软的 PowerPoint 演示文件为 application/vnd.ms-powerpoint 类型。

常见的 MIME 类型有数百个，实验性或用途有限的 MIME 类型则更多。如需了解更多MIME类型可查阅《HTTP权威指南》中文版附录D。

事务

客户端是怎样通过 HTTP 与 Web 服务器及其资源进行事务处理的。一个 HTTP 事务由一条（从客户端发往服务器的）请求命令和一个（从服务器发回客户端的）响应结果组成。这种通信是通过名为 HTTP 报文（HTTP message）的格式化数据块进行的。

HTTP报文

HTTP 报文是由一行一行的简单字符串组成的。HTTP 报文都是纯文本，不是二进制代码，所以人们可以很方便地对其进行读写。

从 Web 客户端发往 Web 服务器的 HTTP 报文称为请求报文（request message）。从服务器发往客户端的报文称为响应报文（response message），此外没有其他类型的HTTP 报文。HTTP 请求和响应报文的格式很类似。

HTTP 报文包括以下三个部分。

• 起始行（start line）
  报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。
• 首部字段（header）
  起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值，为了便于解析，两者之间用冒号（:）来分隔。首部以一个空行结束。添加一个首部字段和添加新行一样简单。
• 报文主体（body）
• 主体空行之后就是可选的报文主体，其中包含了所有类型的数据。请求主体中包括了要发送给 Web 服务器的数据；响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的，而主体则不同，主体中可以包含任意的二进制数据（比如图片、视频、音轨、软件程序）。当然，主体中也可以包含文本。

在图中，浏览器发送了一条 HTTP 请求报文。这条请求的起始行中有一个 GET命令，且本地资源为 /tools.html。这条请求说明它使用的是 1.0 版的 HTTP 协议。请求报文没有主体，因为从服务器上 GET 一个简单的文档不需要请求数据。

服务器会回送一条 HTTP 响应报文。这条响应中包含了 HTTP 的版本号（HTTP/1.0）、一 个 成 功 状 态 码（200）、 一 个 描 述 性 的 原 因 短 语（OK）， 以 及 一 块 响 应 首 部 字段，在所有这些内容之后跟着包含了所请求文档的响应主体。Content-Length首部说明了响应主体的长度（单位：字节），Content-Type 首部说明了文档的 MIME 类型。

请求报文

语法格式

响应报文

语法格式（相比较请求报文，只有起始行的语法不同）

• 方法（method）
  客户端希望服务器对资源执行的动作，是一个单独的单词，比如GET、POST、HEAD等等。
• 请求URL（request-URL）
  指定了所请求的资源，或者URL路径组件的完整URL。
• 版本（version）
  报文所使用的HTTP协议的版本号，其格式为HTTP/<major>.<minor>，其中主版本号（major）和次版本号（minor）都是整数。
• 状态码（status-code）
  这三位数字描述了请求过程中发生的情况，每个状态码的第一位数字都用于描述状态的一般类别（成功、出错等）
• 原因短语（reason-phrase）
  数字状态码的可读版本，增加了状态码的可读性，但原因短语只对人类有意义，程序只处理数字状态码。
• 首部（headers）
  可以有零个或多个首部字段。每个首部字段都包含一个名字，后面跟着一个冒号（:），然后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行（CRLF）结束的,表示了首部列表的结束和报文主体部分的开始。有些HTTP版本，比如HTTP/1.1，要求有效的请求或响应报文中必须包含特定的首部。
• 报文的主体部分（entity-body）
  报文的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含主体部分，有时，报文只是一个CRLF。

HTTP方法

请求的起始行以方法作为开始，方法用来告诉服务器要做些什么。

HTTP规范中定义了一组常用的请求方法。比如GET方法负责从服务器获取数据，POST方法会向服务器发送需要处理的数据，OPTIONS方法用于确认服务器的一般功能或web服务器处理特定资源的能力。

常用的HTTP方法

并不是所有的服务器都实现了以上7种方法。而且由于HTTP设计得易于扩展，所以除了这些方法之外，其他服务器可能还会实现一些自己的请求方法。这些附加的方法是对HTTP规范的扩展，因此被称为扩展方法。

状态码

请求报文中的方法是告诉服务器要做什么，那响应报文中的状态码则是告诉客户端发生了什么事情。

每条 HTTP 响应报文返回时都会携带一个状态码，且位于起始行中。状态码是一个三位数字的代码，告知客户端请求是否成功，或者是否需要采取其他动作。

伴随着每个数字状态码，HTTP 还会发送一条解释性的“原因短语”文本。包含文本短语主要是为了进行描述，所有的程序处理过程使用的都是数字码。

HTTP 软件处理下列状态码和原因短语的方式是一样的。

200 OK
200 Document attached
200 Success
200 All’s cool, dude

状态码的分类

常见状态码

• ==2XX——表明请求被正常处理了==
  200 OK：请求已正常处理。
  204 No Content：请求处理成功，但没有任何资源可以返回给客户端，一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
  206 Partial Content：是对资源某一部分的请求，该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。
• ==3XX——表明浏览器需要执行某些特殊的处理以正确处理请求==
  301 Moved Permanently：资源的uri已更新。永久性重定向，请求的资源已经被分配了新的URI，以后应使用资源现在所指的URI。
  302 Found：资源的URI已临时定位到其他位置了，姑且算你已经知道了这个情况了。临时性重定向。和301相似，但302代表的资源不是永久性移动，只是临时性性质的。换句话说，已移动的资源对应的URI将来还有可能发生改变。
  303 See Other：资源的URI已更新，你是否能临时按新的URI访问。该状态码表示由于请求对应的资源存在着另一个URL，应使用GET方法定向获取请求的资源。303状态码和302状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。
  当301,302,303响应状态码返回时，几乎所有的浏览器都会把POST改成GET，并删除请求报文内的主体，之后请求会自动再次发送。
  304 Not Modified：资源已找到，但未符合条件请求。该状态码表示客户端发送附带条件的请求时（采用GET方法的请求报文中包含If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since中任一首部）服务端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304.。
  307 Temporary Redirect：临时重定向。与302有相同的含义。
• ==4XX——表明客户端是发生错误的原因所在==
  400 Bad Request：服务器端无法理解客户端发送的请求，请求报文中可能存在语法错误。
  401 Unauthorized：该状态码表示发送的请求需要有通过HTTP认证（BASIC认证，DIGEST认证）的认证信息。
  403 Forbidden：不允许访问那个资源。该状态码表明对请求资源的访问被服务器拒绝了。（权限，未授权IP等）
  404 Not Found：服务器上没有请求的资源。路径错误等。
• ==5XX——服务器本身发生错误==
  500 Internal Server Error：貌似内部资源出故障了。该状态码表明服务器端在执行请求时发生了错误。也有可能是web应用存在bug或某些临时故障。
  503 Service Unavailable：抱歉，我现在正在忙着。该状态码表明服务器暂时处于超负载或正在停机维护，现在无法处理请求。

*更多状态码详解可翻阅《HTTP权威指南》附录B

首部(消息头)

报文首部，也叫报文消息头，首部和方法配合工作，共同决定了客户端和服务器能做什么事情。在这里仅列出渗透测试员在攻击Web应用程序时可能遇到的消息头。更多消息头可翻阅《HTTP权威指南》附录C

通用消息头

请求消息头

响应消息头

cookie

cookie是大多数Web应用程序所依赖的HTTP协议的一个关键组成部分，攻击者常常通过它来利用Web应用程序中的漏洞。服务器使用cookie机制向客户端发送数据，客户端保存cookie并将其返回给服务器。与其他类型的请求参数（存在于URL查询字符串或消息体中）不同，无须应用程序或用户采取任何特殊措施，随后的每一个请求都会继续重新向服务器提交cookie。

如前所述，服务器使用Set-Cookie响应消息头发布cookie：

Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

然后，用户的浏览器自动将下面的消息头添加到随后返回给同一服务器的请求中：

Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

如上所示，cookie一般由一个名/值对构成，但也可包含任何不含空格的字符串。可以在服务器响应中使用几个Set-Cookie消息头发布多个cookie，并可在同一个Cookie消息头中用分号分隔不同的cookie，将它们全部返回给服务器。

除cookie的实际值外，Set-Cookie消息头还可包含以下任何可选属性，用它们控制浏览器处理cookie的方式。

• expires。用于设定cookie的有效时间。这样会使浏览器将cookie保存在永久性的存储器中，在随后的浏览器会话中重复利用，直到到期时间为止。如果没有设定这个属性，那么cookie仅用在当前浏览器会话中。
• domain。用于指定cookie的有效域。这个域必须和收到cookie的域相同，或者是它的父域。
• path。用于指定cookie的有效URL路径。
• secure。如果设置这个属性，则仅在HTTPS请求中提交cookie。
• HttpOnly。如果设置这个属性，将无法通过客户端JavaScript直接访问cookie。

上述每一个cookie属性都可能影响应用程序的安全，其造成的主要不利影响在于攻击者能够直接对应用程序的其他用户发动攻击。

HTTS

HTTP使用普通的非加密TCP作为其传输机制，因此，处在网络适当位置的攻击者能够截取这个机制。HTTPS本质上与HTTP一样，都属于应用层协议，但HTTPS通过安全传输机制——安全套接层（Secure Socket Layer，SSL）——传送数据。这种机制可保护通过网络传送的所有数据的隐密性与完整性，显著降低非入侵性拦截攻击的可能性。不管是否使用SSL进行传输，HTTP请求与响应都以完全相同的方式工作。

注意：如今的SSL实际上已经由TLS（Transport Layer Security，传输层安全）代替，但后者通常还是使用SSL这个名称。

HTTP代理

HTTP代理服务器是一个协调客户端浏览器与目标Web服务器之间访问的服务器。当配置浏览器使用代理服务器时，它会将所有请求提交到代理服务器，代理服务器再将请求转送给相关Web服务器，并将响应返回给浏览器。大多数代理还使用其他服务，如缓存、验证与访问控制。

值得注意的是，如果使用代理服务器，HTTP的工作机制会出现两方面的差异。

• 当浏览器向代理服务器发布HTTP请求时，它会将完整的URL（包括协议前缀http://与服务器主机名称，在非标准URL中，还包括端口号）插入请求中。代理服务器将提取主机名称和端口，并使用这些信息将请求指向正确的目标Web服务器。
• 当使用HTTPS时，浏览器无法与代理服务器进行SSL握手，因为这样做会破坏安全隧道，使通信易于遭受拦截攻击。因此，浏览器必须将代理作为一个纯粹的TCP级中继，由它传递浏览器与目标Web浏览器之间的所有网络数据，并与浏览器进行正常的SSL握手。浏览器使用CONNECT方法向代理服务器提交一个HTTP请求，并指定URL中的目标主机名称与端口号，从而建立这种中继。如果代理允许该请求，它会返回一个含200状态码的HTTP响应，一直开放TCP连接，从此以后作为目标Web服务器的纯粹TCP级中继。

从某种程度上说，攻击Web应用程序时最有用的工具是一个处在浏览器与目标Web站点之间的专用代理服务器，使用它可以拦截并修改所有使用HTTPS的请求与响应。我们将在第4章开始分析如何使用这种工具。

HTTP身份验证

HTTP拥有自己的用户身份验证机制，使用不同的身份验证方案。

• Basic。这是一种非常简单的身份验证机制，它在请求消息头中随每条消息以Base64编码字符串的形式发送用户证书。
• NTLM。这是一种质询-响应式机制，它使用某个Windows NTLM协议版本。
• Digest。这是一种质询-响应式机制，它随同用户证书一起使用一个随机值MD5校验和。

虽然组织内部经常使用这些身份验证协议访问内联网服务，但因特网上的Web应用程序基本很少使用它们。

错误观点　“基本身份验证并不安全。”

基本身份验证将未加密的证书插入HTTP请求中，因此，人们普遍认为这种协议并不安全，不应该使用它们。但实际上，许多银行使用的基于表单的身份验证也将未加密的证书插入HTTP请求中。
可以使用HTTPS作为传输机制，防止任何HTTP消息受到窃听攻击；每一个具有安全意识的应用程序都应采用这种机制。至少从窃听方面来说，基本身份验证机制并不比今天绝大多数Web应用程序使用的身份验证机制更加糟糕。

同源策略

同源策略是浏览器实施的一种关键机制，主要用于防止不同来源的内容相互干扰。基本上，从一个网站收到的内容可以读取并修改从该站点收到的其他内容，但不得访问从其他站点收到的内容。

如果不使用同源策略，那么，当不知情的用户浏览到某个恶意网站时，在该网站上运行的脚本代码将能够访问这名用户同时访问的任何其他网站的数据和功能。这样，该恶意站点就可以从用户的网上银行进行转账、阅读用户的Web邮件，或在用户网上购物时拦截他的信用卡信息。为此，浏览器实施限制，只允许相同来源的内容进行交互。

实际上，将这一概念应用于各种Web功能和技术会导致各种复杂情况和风险。关于同源策略，需要了解的一些主要特点如下。

• 位于一个域中的页面可以向另一个域提出任意数量的请求（例如，通过提交表单或加载图像）。但该页面本身无法处理上述请求返回的数据。
• 位于一个域中的页面可以加载来自其他域的脚本并在自己的域中执行这个脚本。这是因为脚本被假定为包含代码，而非数据，因此跨域访问并不会泄露任何敏感信息。
• 位于一个域中的页面无法读取或修改属于另一个域的cookie或其他DOM数据。

这些特点可能导致各种跨域攻击，如诱使用户执行操作和捕获数据。此外，由于浏览器扩展技术以各种方式实施同源限制，这一问题变得更加复杂。

编码方案

URL编码

URL只允许使用US-ASCII字符集中的可打印字符（也就是ASCII代码在0x20 ~ 0x7e范围内的字符）。而且，由于其在URL方案或HTTP协议内具有特殊含义，这个范围内的一些字符也不能用在URL中。

URL编码方案主要用于对扩展ASCII字符集中的任何有问题的字符进行编码，使其可通过HTTP安全传输。任何URL编码的字符都以%为前缀，其后是这个字符的两位十六进制ASCII代码。以下是一些常见的URL编码字符：

• %3d代表=；
• %25代表%；
• %20代表空格；
• %0a代表新行；
• %00代表空字节。

另一个值得注意的编码字符是加号（+），它代表URL编码的空格（除%20代表空格外）。

注解　当攻击Web应用程序时，如果需要将以下字符当做数据插入HTTP请求中，渗透测试员必须对它们进行URL编码。

1	空格 % ? & = ; + #

（当然，当修改请求时，往往需要使用这些字符的特殊含义，例如，给查询字符串添加另外一个请求参数。这时应使用这些字符的字面量形式。）

Unicode编码

Unicode是一种为支持全世界所使用的各种编写系统而设计的字符编码标准，它采用各种编码方案，其中一些可用于表示Web应用程序中的不常见字符。
16位Unicode编码的工作原理与URL编码类似。为通过HTTP进行传输，16位Unicode编码的字符以%u为前缀，其后是这个字符的十六进制Unicode码点。例如：

• %u2215代表/；
• %u00e9代表é。

UTF-8是一种长度可变的编码标准，它使用一个或几个字节表示每个字符。为通过HTTP进行传输，UTF-8编码的多字节字符以%为前缀，其后用十六进制表示每个字节。例如：

• %c2%a9代表©；
• %e2%89%a0代表≠。
• 攻击Web应用程序时之所以要用到Unicode编码，主要在于有时可用它来破坏输入确认机制。如果输入过滤阻止了某些恶意表达式，但随后处理输入的组件识别Unicode编码，就可以使用各种标准与畸形Unicode编码避开过滤。

HTML编码

HTML编码是一种用于表示问题字符以将其安全并入HTML文档的方案。有许多字符具有特殊的含义（如HTML内的元字符），并被用于定义文档结构而非其内容。为了安全使用这些字符并将其用在文档内容中，就必须对其进行HTML编码。
HTML编码定义了大量HTML实体来表示特殊的字面量字符，例如：

• "代表”；
• '代表’；
• &代表&；
• <代表<；
• >代表>。

此外，任何字符都可以使用它的十进制ASCII码进行HTML编码，例如：

• "代表"；
• #39;代表’。

或者使用十六进制的ASCII码（以x为前缀），例如：

• "代表”；
• '代表’。

当攻击Web应用程序时，HTML编码主要在探查跨站点脚本漏洞时发挥作用。如果应用程序在响应中返回未被修改的用户输入，那么它可能易于受到攻击；但是，如果它对危险字符进行HTML编码，也许比较安全。

Base64编码

Base64编码仅用一个可打印的ASCII字符就可安全转换任何二进制数据，它常用于对电子邮件附件进行编码，使其通过SMTP安全传输。它还可用于在基本HTTP验证机制中对用户证书进行编码。

Base64编码将输入数据转换成3个字节块。每个块被划分为4段，每段6个数据位。这6个数据位有64种不同的排列组合，因此每个段可使用一组64个字符表示。Base64编码使用以下字符集，其中只包含可打印的ASCII字符：

如果最后的输入数据块不能构成3段输出数据，就用一个或两个等号（=）补足输出。

例如，The Web Application Hacker’s Hand book的Base64编码为：

许多Web应用程序利用Base64编码在cookie与其他参数中传送二进制数据，甚至用它打乱敏感数据以防止即使是细微的修改。应该总是留意并解码发送到客户端的任何Base64数据。由于这些数据使用特殊的字符集，而且有时会在字符串末尾添加补足字符（=），因此可以轻易辨别出Base64编码的字符串。

十六进制编码

许多应用程序在传送二进制数据时直接使用十六进制编码，用ASCII字符表示十六进制数据块。例如，对cookie中的用户名daf进行十六进制编码，会得到以下结果：
646166
和Base64编码的数据一样，十六进制编码的数据通常也很容易辨认。为了解十六进制编码的功能应当对服务器发送到客户端的任何十六进制数据进行解码。

远程和序列化框架

近些年出现了各种用于创建用户界面的框架，这些框架中的客户端代码可以远程访问服务器端实施的编程API。利用这些框架，开发者可以在一定程度上忽略Web应用程序的分布式本质，而以与开发传统桌面应用程序类似的方式编写代码。这些框架通常提供客户端上使用的存根API。它们还能够自动处理以下两个任务：通过这些API远程调用相关服务器端功能，对传送给上述功能的任何数据进行序列化。
这类远程和序列化框架包括：

• Flex和AMF；
• Silverlight和WCF；
• Java序列化对象。

MD5编码

常见的数据交换格式

JSON

JavaScript对象表示法（JSON）是一种可用于对任意数据进行序列化的简单数据交换格式。JSON可直接由JavaScript解释器处理。Ajax应用程序经常使用JSON，以替换最初用于数据传输的XML格式。通常，如果用户执行某个操作，客户端JavaScript将使用XMLHttpRequest将该操作传送到服务器。服务器则返回一个包含JSON格式的数据的轻量级响应。然后，客户端脚本将处理这些数据，并对用户界面进行相应地更新。

例如，基于Ajax的Web邮件应用程序可能提供显示所选联系人的详细资料的功能。如果用户单击某位联系人，浏览器将使用XMLHttpRequest检索所选联系人的详细资料，并使用JSON返回这些资料：

客户端脚本将使用JavaScript解释器来处理JSON响应并基于其内容更新用户界面的相关部分。
此外，当前的应用程序还将JSON用于封装传统上位于请求参数中的数据。例如，如果用户更新联系人的详细资料，则可以使用以下请求将新信息传送至服务器：

XML

可扩展标记语言（XML）是一种机器可读格式的数据编码规范。与其他标记语言一样，XML格式将文档划分为内容（数据）和标记（给数据作注解）。

标记主要用标签表示，它们包括起始标签、结束标签和空元素标签：

起始和结束标签成对出现，其中可以包括文档内容或子元素：

标签可以包含以名/值对出现的属性：

XML之所以可扩展，是因为它可以使用任意数量的标签和属性名。XML文档通常包含文档类型定义（DTD），DTD定义文档中使用的标签、属性及其组合方式。

服务器端和客户端Web应用程序广泛采用XML及由XML派生的技术，我们将在本章后面部分介绍这些内容。

HTTP相关资料

• HTTP Pocket Reference（《HTTP 口袋书》）
  Clinton Wong 著，O’Reilly & Associates 出版公司。这本书详细介绍了 HTTP，可以作为构成 HTTP 事务的首部和状态码的快速参考手册。
• http://www.w3.org/Protocols/
  这个 W3C 的 Web 页面中包含了很多与 HTTP 协议有关的重要链接。
• http://www.ietf.org/rfc/rfc2616.txt
  RFC2616“超文本传输协议——HTTP/1.1”是当前 HTTP 协议版本 HTTP/1.1 的官方规范。这个规范是一本编写流畅、组织良好而且非常详细的 HTTP 参考手册，但并不适于那些希望了解 HTTP 底层概念和动因，或者原理与实际应用之间区别的读者阅读。希望本书能够对这些底层概念进行补充，以便读者更好地使用这个规范。
• http://www.ietf.org/rfc/rfc1945.txt
  RFC1945“超文本传输协议——HTTP/1.0”是一个描述了 HTTP 现代基础的知识性 RFC。它详细描述了编写此规范时已得到官方认可，且具有“最佳实践”行为的 Web 应用程序。还讨论了一些虽被 HTTP/1.1 所摒弃，但在一些老旧的应用程序中仍在广泛使用的行为。
• http://www.w3.org/Protocols/HTTP/AsImplemented.html
  这个 Web 页面介绍了 1991 年的 HTTP/0.9 协议，这个协议只实现了 GET 请求，而且不包含内容类型。

本文参考资料

《HTTP权威指南》 (图灵程序设计丛书) – [美]David Gourley Brian Totty Marjorie Sayer Sailu Reddy Aushu Aggarwal.azw3

《黑客攻防技术宝典》 Web实战篇(第2版) (图灵程序设计丛书•网络安全系列) – Dafydd Stuttard.epub