3. 第三部分

第七章 确保Web安全的HTTPS

使用HTTPS通信机制可以有效防止信息窃听或身份伪装等安全问题。

1.HTTP缺点

　　【通信使用明文（不加密）】：内容容易被窃听。

　　　　加密处理防止被窃听。根据加密的对象分为：

　　　　①通信的加密：通过SSL（安全套接层）或TLS（安全传输协议）的组合使用，加密HTTP的通信内容。 使用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP称为HTTPS（超文本传输安全协议）。

　　　　②内容的加密：把HTTP报文里所含的内容进行加密处理。

　　【不验证通信方身份】：可能遭遇伪装。

　　　　虽然使用HTTP协议无法确定通信方，但是如果使用SSL则可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可以用于确定方。证书由值得信任的第三方机构颁发，用于证明客户端是真实存在的。

　　【无法证明报文的完整性】：可能会被篡改。

　　　　请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击者称为中间人攻击。HTTP有PGP和MD5等方法确定报文完整性，但是并不是百分百正确的。有必要使用HTTPS，SSL提供认证和加密处理及摘要功能。

2. HTTP+加密+认证+完整性保护=HTTPS

 　　经常会在Web登陆界面和购物结算界面等使用HTTPS通信。使用HTTPS通信时，不再用http://，而是改用https://。另外当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏会出现一个带锁的标记。

　　

　　【HTTP是身披SSL外壳的HTTP】HTTPS只是HTTP通信接口部分使用SSL和TLS协议代替而已。通常HTTP直接和TCP通信，当使用SSL时，演变成HTTP先和SSL通信，再由SSL和TCP通信。在采用SSL之后，HTTP就拥有了加密、证书和完整性保护功能。

　　【HTTPS加密技术】

 　　①共享密钥方式（对称密钥方式）：加密和解密使用同一种密钥。缺点：以共享密钥方式加密时必须将密钥也发送给对方。但是如何安全转交密钥成问题。

　　②公开密钥方式：使用一对非对称密钥，一把叫做私有密钥（只有自己知道），一把叫做公开密钥（大家都知道）。发送密文的一方使用对方的公开密钥进行加密处理，接受方收到加密信息后，在用自己的密钥进行解密。缺点：恢复信息原文十分困难。

　　③HTTPS使用混合加密机制：使用公开密钥方式传输在共享密钥加密中要使用的密钥，然后再使用共享密钥加密进行通信。

 　　 ④证明公开密钥正确性的证书：公开密钥加密方式存在一些问题，那就是无法证明公开密钥本身就是真正的公开密钥。为了解决该问题，可以使用相关机构颁发的公开密钥证书。

　　【HTTPS的安全通信机制】在HTTPS通信过程中应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保证报文的完整性。

　　【SSL缺点】：慢！通信慢、消耗大量CPU和内存资源，处理速度慢。

---

第八章 确认访问用户身份的认证

某些Web页面只想让特定的人浏览，或者仅本人可见。而认证机制可以达到这个目标。

 1. 认证概念

　　为了核对用户信息，通常需要一些这些信息：密码、动态令牌、数字证书、生物证书、IC卡等。

　　HTTP/1.1使用的认证方式：BASIC认证（基本认证）、DIGEST认证（摘要认证）、SSL客户端认证、FromBase认证（基于表单认证）。

2.BASIC认证

　　【认证步骤】：

　　步骤 1： 当请求的资源需要 BASIC 认证时，服务器会随状态码 401Authorization Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式（BASIC） 及 Request-URI 安全域字符串（realm）。

　　步骤 2： 接收到状态码 401 的客户端为了通过 BASIC 认证，需要将用户 ID 及密码发送给服务器。发送的字符串内容是由用户 ID 和密码构成，两者中间以冒号（:）连接后，再经过 Base64 编码处理。

　　步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI资源的响应。

　　【缺点】容易被窃听；一般的浏览器无法实现认证注销操作；不够便捷灵活；

 2. DIGEST 认证

　　DIGEST认证使用质询/响应的方式，但不会像BASIC认证那样直接发送明文密码。

　　质询/响应：一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。

　　【认证步骤】

　　步骤 1： 请求需认证的资源时，服务器会随着状态码 401Authorization Required，返 回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。

　　步骤 2： 接收到 401 状态码的客户端，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。

　　步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。

　　【缺点】安全等级还不是太高；不灵活；

3. SSL客户端认证

　　SSL客户端认证是使用HTTPS的客户端证书完成认证的方式，凭借客户端证书认证，服务器可确认访问是否来源于已经登陆的客户端。

　　【认证步骤】

　　为达到 SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。

　　步骤 1： 接收到需要认证资源的请求，服务器会发送 CertificateRequest 报文，要求客户端提供客户端证书。

　　步骤 2： 用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

　　步骤 3： 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。

　　【双因素认证】SSL客户端认证不仅仅依靠证书来完成认证，一般会与基于表单认证组合形成一种双因素认证。认证过程中不仅需要密码这一因素，还需要申请认证者提供其他持有信息。密码是为了确认这是用户本人的行为，SSL客户端证书用来认证客户端计算机。

4. 基于表单认证（最常用）

　　基于表单的认证方法并不是在 HTTP 协议中定义的。客户端会向服务器上的 Web 应用程序发送登录信息（Credential），按登录信息的验证结果认证。根据 Web 应用程序的实际安装，提供的用户界面及认证方式也各不相同。（）

 　　【Session管理以及Cookie应用】基于表单认证本身是通过服务器端的 Web 应用，将客户端发送过来的用户 ID 和密码与之前登录过的信息做匹配来进行认证的。但鉴于 HTTP 是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用 Cookie 来管理 Session，以弥补 HTTP 协议中不存在的状态管理功能。

　　步骤 1： 客户端把用户 ID 和密码等登录信息放入报文的实体部分，通常是以 POST 方法把请求发送给服务器。而这时，会使用 HTTPS通信来进行 HTML表单画面的显示和用户输入数据的发送。

　　步骤 2： 服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID 绑定后记录在服务器端。

　　步骤 3： 客户端接收到从服务器端发来的 Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。