第11章 客户端识别与cookie机制

用户识别机制：

• 承载用户身份信息的 HTTP 首部
• 客户端 IP 地址跟踪，通过用户的 IP 地址对其进行识别
• 用户登录，用认证方式来识别用户
• 胖 URL，一种在 URL 中嵌入识别信息的技术
• cookie，一种功能强大且高效的持久身份识别技术

HTTP首部

From、User-Agent、Referer 首部不足以实现可靠的识别。

客户端IP地址

通常在 HTTP 首部并不提供客户端的 IP 地址，但 Web 服务器可以找到承载 HTTP 请求的 TCP 连接另一端的 IP 地址。

缺点：

1. 客户端 IP 地址描述的是机器而不是用户，无法区分共享同一台计算机的多个用户。
2. 因特网服务提供商会在用户登录时为其动态分配 IP 地址。
3. 很多用户都是通过网络地址转换（NAT）防火墙来浏览网络内容的。NAT 隐藏防火墙后的实际客户端 IP 地址，将其转换为一个共享的防火墙 IP 地址和不同的端口号。
4. HTTP 代理和网关通常会打开一些新的到原始服务器的 TCP 连接。Web 服务器看到的是代理服务器的 IP 地址，而不是客户端的。有些为了解决这个问题，会添加 Client-IP 或 X-Forwarded-For 首部来保存原始的 IP 地址，但是不是所有代理都这样。

用户登录

Web 服务器通过要求用户通过用户名和密码进行认证（登录）来显式地询问用户是谁。HTTP 包含一种内部机制，可以用 www-Authenticate 首部和 Authorization 首部向 Web 站点传送用户的相关信息。一旦登录，浏览器就可以不断在每条发往这个站点的请求中发送这个登录信息了。

如果服务器希望在为用户提供对站点的访问之前，先行登录，可以向浏览器回送一条 HTTP 响应代码 401 Login Required，然后浏览器显示一个登录对话框，并用 Authorization 首部在下一条对服务器的请求中提供这些信息。

但是，登录多个 Web 站点是很繁琐的。当你从一个站点浏览到另一个站点时，需要在每个站点上登录，而且很有可能要为不同的站点记住不同的用户名和密码。胖 URL 可以解决这个问题。

胖URL

有些站点会为每个用户生成特定版本的 URL 来追踪用户身份。通常会对真正的 URL 进行扩展，在 URL 路径开始或结束的地方添加一些状态信息。用户浏览站点时，Web 服务器会动态生成一些超链，继续维护 URL 中的状态信息。改动后包含用户状态信息的 URL 就是 胖 URL（fat URL）。

缺点：

1. 丑陋的 URL
2. 无法共享 URL
3. 破坏缓存
4. 额外的服务器负荷
5. 逃逸口：当用户不追随修改过的链接时，就好丢失进展信息，得重新开始
6. 在会话间是非持久的

Cookie

Cookie 是当前识别用户，实现持久会话的最好方式。

Cookie的类型

• 会话 Cookie：是一种临时 Cookie，它记录了用户访问站点时的设置和偏好，用户退出浏览器时，Cookie 就被删除了。
• 持久 Cookie：它们存储在硬盘上，浏览器退出，计算机重启时仍然存在，通常会用持久 Cookie 维护某个用户会周期性访问的站点的配置文件或登录名。它的生存时间更长一些。

Cookie是如何工作的

用户首次访问站点时，Web 服务器对用户一无所知，所以服务器通过 Set-Cookie 或 Set-Cookie2 HTTP 响应首部给用户“贴上”一个独有的 Cookie，这样当用户下次再来的时候，就可以识别出这个用户了。Cookie 中包含了一个由 name=value 的信息构成的任意列表。

Cookie罐：客户端的状态

因为浏览器要负责存储 Cookie 信息，所以此系统被称为客户端侧状态，Cookie 的正式名称为 HTTP 状态管理机制。

网景的 Navigator 会将 Cookie 存储在 cookies.txt 文本文件中。

不同站点使用不同的Cookie

浏览器内部的 Cookie 罐中可以有成百上千个 Cookie，但通常只向每个站点发送 2-3 个Cookie。

Set-Cookie: XSRF-TOKEN=eyJpdiI6IjFwaU92YUJIWEtVblN0b1AwSkRZeEE9PSIsInZhbHVlIjoiZjkzM1wvb3ZSMzBKZzU5XC9YUlA5c3ZjRk5zcXlhc0tra1h4d3MwQTVSMTJOOVoxQlVhVkd4SEJ2YzB2Rm44Q1B0NmNKeEZWTGtJRmdwZ2VpRVg2S3pUekRoNHBKSmd5d0tsaTJncWFzV01MTjVRbkZjVzI5a2pSSjBzckZWMmRiQSIsIm1hYyI6ImJmMjE0NWE4NGQ2YTQ5ODQxMWFmMjI4YjE4ODNmZjE1MzhlMTRiYTg4NTRhNDA5Y2UwNzI2Y2RhZmIzZGI0NWIifQ%3D%3D; expires=Thu, 25-Mar-2021 15:21:55 GMT; Max-Age=43200; path=/; domain=.learnku.com

1. Cookie 的域属性

   domain=.learnku.com

   告诉浏览器将 Cookie 发送给域“.learnku.com”中的所有站点。

2. Cookie 路径属性

   通过 path 属性，允许用户将 Cookie 与部分 Web 站点关联起来。在 path 值列出的 URL 路径前缀下的所有 Cookie 都是有效的。

Cookie成分

Cookie 规范有两个版本：Cookies 版本0 （Netscape）和 Cookies 版本1（RFC2965 ）。

Cookies版本0

1. 版本0的 Set-Cookie 首部

   Set-Cookie属性	描述
   Name-Value	必需的。
   Expires	可选的。指定 Cookie 的实际生存期。
   Domain	可选的。只向指定域发送 Cookie。
   Path	可选的。为路径分配 Cookie。
   Secure	可选的。只在使用 SSL 才发送 Cookie。

2. 版本0的 Cookie 首部

   Cookie: session-id=002-1145265-8016838; sidbar_percent=24.03846153846154; width_percent=75.96153846153845%; _gat=1

Cookies版本1

1. 版本1的Set-Cookie2首部

   Set-Cookie2属性	描述
   Name-Value	必需的。
   Version	必需的。对应 Cookie 规范的版本，RFC 为版本1。
   Comment	可选的。说明服务器准备如何使用这个 Cookie。
   CommentURL	可选的。提供一个 URL 指针，只向描述 Cookie 目的及策略的文档。
   Discard	可选的。在客户端终止时，放弃这个 Cookie。
   Domain	可选的。只向指定域发送 Cookie。
   Max-Age	可选的。设置以秒为单位的 Cookie 生存期。
   Path	可选的。为路径分配 Cookie。
   Port	可选的。设置可以应用 Cookie 的端口列表。
   Secure	可选的。只在使用 SSL 才发送 Cookie。

2. 版本1的Cookie首部

   关键字由 $ 开头。

   Cookie: $Version="1"; ID="1222"; $Domain=".jaons.com"

第12章 基本认证机制

认证

认证就是要给出一些身份证明。

HTTP的质询/响应认证框架

HTTP 提供了一个原生的质询/响应框架，简化了对用户的认证过程。

1. Web 应用程序收到一条 HTTP 请求报文时，服务器没有按照请求执行动作，而是以一个“认证质询”进行响应（401 Unauthorized），要求用户提供一些保密信息来证明，从而对其进行质询。
2. 用户再次发起请求时，要附上保密证书（用户名和密码）。如果证书不匹配，服务器可以再次质询客户端，或产生一条错误信息。如果证书匹配，就可以正常完成请求了。

认证协议与首部

HTTP 通过一组可定制的控制首部，为不同的认证提供一个可扩展框架。HTTP 定义了两个官方认证协议：基本认证和摘要认证。

认证 4 个步骤：

安全域

WWW-Authenticate 质询中包含一 realm 指令。Web 服务器会将受保护的文档组织成一个安全域（security realm），每个安全域都可以有不同的授权用户集。

假设 Web 服务器建立两个安全域：一个用于公司的财务信息，另一个用于个人家庭文档。不同用户对各个安全域的访问权限是不同的。

基本认证

基本认证是最流行的 HTTP 认证协议，几乎每个客户端和服务器都实现了基本认证实例。

在基本认证中，Web 服务器可以拒绝一个事务，质询客户端，请客户端提供有效的用户名和密码。服务器会返回 401 来初始化认证质询，并用 WWW-Authenticate 响应首部指定要访问的安全域。浏览器收到质询后，会打开一个对话框，请求用户输入这个域的用户名和密码。然后将用户名和密码稍加扰码，再用 Authorization 请求首部回送给服务器。

基本认证实例

  - （a）用户请求私人家庭相片 /family/jeff.jpg
  - （b）服务器回送 401 Authorization Require，对客户端进行质询，同时回送 WWW-Authenticate 首部。这个首部请求对 Family 域进行基本认证。
  - （c）浏览器收到 401，弹出对话框。用户输入信息，浏览器会用一个冒号将其连接起来，编码成“经过扰码的” Base-64 形式，将其放在 Authorization 首部中回送。
  - （d）服务器对用户名和密码进行解码，验证正确性，然后返回 HTTP 200 OK 报文。

Base-64 用户名/密码编码

HTTP 基本认证将（由冒号分隔的）用户名和密码用 Base-64 编码方式进行编码。

用户名:密码  --Base-64编码-->  Yhjfkdjfksdnik(编码后的) 

代理认证

中间代理服务器也可以实现认证功能，可以在代理服务器对访问策略进行集中管理。代理的步骤与 Web 服务器身份证步骤相同，但首部和状态码有差异。

基本认证的安全缺陷

1. 基本认证会通过网络发送经过 Base-64 编码的用户名和密码，这很容易通过反向编码过程进行解码。如果要阻止用户名和密码被拦截，就要通过 SSL 加密通道发送所有的 HTTP 事务，或者用更安全的认证协议（例如摘要认证）。
2. 即使密码是以更难解码的方式加密，第三方用户仍然可以捕获被修改过的用户名和密码，并将修改过的用户名和密码重放给原始服务器，以获得对服务器的访问权。没有措施可以防止这些重放攻击。
3. 即使将基本认证用于一些不重要的应用程序，但用户的不良习惯（使用同一个密码）也会让它变得很危险（去访问重要的应用程序）。
4. 基本认证没有提供任何针对代理和作为中间人的中间节点的防护措施，它们没有修改认证首部，但却修改了报文的其余部分，这样严重地改变了事务的本质。
5. 假冒服务器很容易骗过基本认证。如果用户实际连接到一台恶意服务器或网关的时候，能够让用户相信他连接的是一个受基本认证保护的合法主机，攻击者就可以请求用户输入密码，将其存储起来，然后捏造一条错误信息传送给用户。

第13章 摘要认证

摘要认证的改进

摘要认证是另一种 HTTP 认证协议，它针对基本认证的缺陷，做了如下改进：

• 永远不会以明文方式在网络上发送密码
• 可以防止恶意用户捕获并重放认证的握手过程
• 可以有选择地防止对报文内容的篡改
• 防范其他几种常见的攻击方式

用摘要保护密码

摘要认证遵循的箴言是“绝不通过网络发送密码”。客户端不会发送密码，而是会发送一个“指纹”或密码的“摘要”，这是密码的不可逆扰码。客户端和服务器都知道这个密码，因此服务器可以验证所提供的摘要是否与密码相匹配。只拿到摘要的话，除了将所有密码都拿来试试之外，没有其他方法可以找出摘要来自哪个密码。

• （c）客户端传递密码的摘要，证明它是知道密码的。服务器将客户端提供的摘要与自己计算得到的摘要进行比较，以验证用户是否知道密码。另一方在不知道密码的情况下，很难伪造出正确的摘要。

单向摘要

摘要是“对信息主体的浓缩”。摘要是一种单向函数，主要用于将无限的输入值转为有限的浓缩输出值。常见的摘要函数 MD5，会将任意长度的字节序列转换为一个 128 位的摘要。摘要函数也称为加密的校验和、单向散列函数或指纹函数。

用随机数防止重放攻击

除了使用单向摘要并不能避免危险，因为如果摘要被截获，并一遍遍地重放给服务器，摘要和密码一样好用。

为了防止重放攻击的发生，服务器可以向客户端发送一个称为随机数的特殊令牌，这个数会经常发生变化。客户端在计算摘要之前要先将这个随机数令牌附加到密码上去，这使得摘要会随着随机数的每一变化而变化。

记录下的密码只对特定的随机数有效，而没有密码的话，攻击者就无法计算出正确的摘要，这样就可以防止重放攻击的发生。随机数是在 WWW-Authenticate 质询中从服务器传送给客户端的。

摘要认证的握手机制

• （4）将摘要放在一条 Authorization 报文中发回服务器。如果客户端要对服务器进行认证，可以发送客户端随机数。
• （5）服务器接收摘要、选中的算法以及支撑数据，计算出与客户端相同的摘要。然后服务器将本地生成的摘要与网络传送过来的摘要进行比较，验证是否匹配。如果客户端反过来用客户端随机数对服务器进行质询，就会创建客户端摘要。服务器可以预先将下一个随机数计算出来，提前将其传递给客户端，这样下次客户端就可以延长线发送正确的摘要了。

摘要的计算

摘要算法的输入数据

摘要是根据以下三个组件计算出来的。

• 由单向散列函数 H(d) 和摘要 KD(s,d) 组成的一对函数，其中 s 表示密码， d 表示数据。
• 一个包含了安全信息的数据块，包括密码，称为 A1。
• 一个包含了请求报文中非保密属性的数据块，称为 A2。

H 和 KD 处理两块数据 A1 和 A2，产生摘要。

算法H(d)和KD(s,d)

摘要认证支持对各种摘要算法的选择，例如 MD5 和 MD5-sess（sess 表示会话）。 默认 MD5。

用函数 H 来计算数据的 MD5，用摘要函数 KD 来计算以冒号连接的密码和非保密数据的 MD5。例如：

H(data) = MD5(data)
KD(secret,data) = H(concatenate(secret:data))

与安全性相关的数据（A1）

A1 数据块是密码和受保护信息的产物，它包含用户名、密码、保护域和随机数等内容。A1 只涉及安全信息，与底层报文自身无关。A1 会与 H、KD 和 A2 一同用于摘要计算。

预授权

安全性考虑

首部篡改

摘要认证的重点在于提供一种防篡改认证机制，但并不一定要将这种保护扩展到数据上去。具有一定保护级别的首部只有 WWW-Authenticate 和 Authorization。

重放攻击

指的是有人将从某个事务中窃取的认证证书用于另一个事务。

多重认证机制

服务器支持多重认证机制（基本认证和摘要认证）时，通常会在 WWW-Authenticate 首部提供选项。

词典攻击

词典攻击是典型的密码猜测型攻击方式。恶意用户对某个事务进行窃听，并对随机数/响应对使用标准的密码猜测程序。

恶意代理攻击和中间人攻击

随着重定向技术和拦截代理的出现，用户有可能意识不到他的请求穿过了某个代理。如果这些代理中有恶意的，就会使客户端置于中间人攻击之下。

选择明文攻击

使用摘要认证的客户端会用服务器提供的随机数来生成响应，但如果中间有一个被入侵的或恶意的代理在拦截流量（或者是恶意的原始服务器），就很容易为客户端的响应计算提供随机数。使用已知密钥来计算响应可以简化响应的密码分析过程。

选择明文攻击的变体形式：

• 预先计算的词典攻击：发起攻击者会用预先确定的随机数和常见密码的变化形式产生一组响应。向客户端发送预先确定的随机数，从客户端获取响应，在生成的词典搜索，寻找匹配项。如果有匹配项，那么攻击者就捕获了这个用户的密码。
• 批量暴力型攻击：它没有试图去匹配预先计算出来的摘要，而是用一组机器枚举了指定空间内所有可能的密码。随着机器运行速度变得越来越快，暴力型攻击的可行性也越强。

存储密码

摘要认证机制将对比用户的响应与服务器内部存储的内容，如果摘要密码文件被入侵了，攻击者马上就能使用域中所有的文件，不需要再进行解码了。

第14章 安全HTTP

保护HTTP的安全

HTTPS 是最流行的 HTTP 安全形式。HTTPS 方案的 URL 以 https:// 开头

数字加密

密码

对文本进行编码，使偷窥者无法识别的算法。

密码机

密码机可以用更复杂的密码来快速、精确地对报文进行编解码。

使用了密钥的密码

对密码机输入正确的密码参数（密钥 key：改变密码行为的数字化参数），解密过程才能正确进行。

数字密码

给定明文报文 P、编码函数 E、数字编码密钥 e，就可以生成密文 C。

给定生成密文 C、解码函数 D、数字解码密钥 d，就可以解码为明文 P。

对称密钥加密技术

对称密钥加密技术使用的 e 和 d 相等，统称为密钥 k。

流行的对称密钥加密算法有：DES、Triple-DES、RC2、RC4。

建立共享密钥

对称密钥加密技术的缺点之一就是发送者和接收者在互相对话之前，一定要有一个共享的保密密钥。如果有 N 个节点，每个节点要和 N-1 个节点进行安全对话，总共需要 N² 个保密密钥。

公开密钥加密技术

公开密钥加密技术没有为每对主机使用单独的加密/解密密钥，而是使用了两个非对称密钥：一个用来对主机报文编码，另一个用来对主机报文解码。

编码密钥是众所周知的，但只有主机才知道私有的解密密钥。这样每个人都能找到某个特定主机的公开密钥，密钥的建立变得更加简单。但解码密钥是保密的，只有接收端才能对发送给它的报文进行解码。

数字签名

除了加/解密报文之外，还可以用加密系统对报文进行签名（sign），以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名。

签名是加了密的校验和

数字签名是附加在报文上的特殊加密校验码。通常是用非对称公开密钥技术产生的。

使用数字签名的好处：

1. 签名可以证明是作者编写了这条报文，只有作者才有私有密钥，因此只有作者才能计算出这些校验和。
2. 签名可以防止报文被篡改。如果有恶意攻击在报文传输过程中对其进行了修改，校验和就不能匹配了。由于校验和只有作者才能产生，所以攻击者无法为篡改的报文伪造正确的校验码。

• 节点 A 将变长报文提取为定长的摘要。
• 节点 A 对摘要应用了一个“签名”函数，这个函数会将作者的私有密钥作为参数。
• 节点 A 将计算出的签名附加在报文的末尾，并将报文和签名都发送给 B。
• 节点 B 使用公开密钥的反函数，检查拆包后的摘要与节点 B 的摘要是否匹配。如果不匹配，说明报文被篡改。

数字证书

数字证书（certs）包含了由某个受信任组织担保的用户或公司的相关信息。

证书的主要内容

用证书对服务器进行认证

通过 HTTPS 建立了一个安全 Web 事务后，浏览器都会自动获取所连接服务器的数字证书。如果服务器没有证书，安全连接就会失败。服务器证书中包含很多字段。

浏览器收到证书时会对签名颁发机构进行检查。入股这个机构是个很权威的公共签名机构，浏览器可能已经知道其公开密钥了。

HTTPS——细节介绍

HTTPS概述

HTTPS 就是在安全的传输层上发送的 HTTP。HTTPS 没有将未加密的 HTTP 报文发送给 TCP，而是先将其发送给了一个安全层，对其进行加密。HTTP 安全层是通过 SSL 及其现代替代协议 TLS 来实现的。

建立安全传输

• （a）在未加密 HTTP 中，客户端会打开一条到 Web 服务器端口 80 的 TCP 连接，发送一条请求报文，接收一条响应报文，关闭连接。
• （b）而在 HTTPS 中，客户端首先打开一条到 Web 服务器端口 443 的连接。一旦建立了 TCP 连接，客户端和服务器就会初始化 SSL 层，对加密参数进行沟通，并交换密钥。握手完成之后，SSL 初始化就完成了，客户端就可以将加密的请求报文发送给安全层了。在将报文发送给 TCP 之前，要先加密。

SSL握手

在发送加密报文之前，客户端和服务器要进行一次 SSL 握手，握手要完成一下工作：

• 交换协议版本号
• 选择两端都了解的密码
• 对两端的身份进行认证
• 生成临时的会话密钥，以便加密信道

服务器证书

SSL 支持双向认证，将服务器证书承载回客户端，再将客户端的证书回送给服务器。（现在，服务器很少使用客户端证书）

另一方面，HTTPS 事务总是要求使用服务器证书的，帮助用户在发送重要信息之前评估服务器的信任度。