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

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

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

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

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

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

TCP 提供了：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

语法格式

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

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

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

常用的HTTP方法

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

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

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

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

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

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

状态码的分类

常见状态码

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

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

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的方式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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远程调用相关服务器端功能，对传送给上述功能的任何数据进行序列化。
这类远程和序列化框架包括：

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

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

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

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

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

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

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

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

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

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

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

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！