第7章
确保Web安全的HTTPS
在HTTP协议中有可能存在信息窃听或身份伪装等安全问题。使用HTTPS通信机制可以有效的防止这些问题。
7.1 HTTP的缺点
● 通信使用明文（不加密），内容可能会被窃听
● 不验证通信方的身份，因此有可能遭遇伪装
● 无法证明报文的完整性，所以有可能已遭篡改
7.1.1 通信明文可能会被窃听
由于HTTP本身不具备加密功能，所以也无法做到对通信整体进行加密。即，HTTP报文使用明文方式发送。
TCP/IP是可能被窃听的网络
按TCP/IP协议族的工作机制，通信内容在所有通信线路上都有可能遭到窃听。
即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。 只是说如果通信经过加密，就有可能让人无法破解
报文信息的含义，但加密处理后的报文信息本身还是会被看到的。
窃听相同的通信并非难事。只要收集在互联网上流动的数据包就可以了。对于收集来的数据包的解析工作，交给那些抓包工具就可以了。
加密处理防止被窃听
通信的加密
一种是通信加密。HTTP协议中没有加密机制，但可以空过和SSL（Secure Socket Layre 安全套接层）或者TLS（Transport Layer Security安全层传输协议）组合使用，加密HTTP的通信内容
用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure 超文本传输安全协议）或 HTTP over SSL
内容加密
由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。
7.1.2　不验证通信方的身份就可能遭遇伪装
HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真
的返回到实际提出请求的客户端”等类似问题。

任何人都可以发起请求
无法确定发送至目标的Web服务器是否按真实意图返回响应的那台服务器。有可能是以伪装的Web服务器。
无法确定响应返回的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
无法确定正在通信的双方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
无法判定请求来自何方、出自谁手。
即使是无意义的请求也会照单全收。无法阻止海量请求下的Dos攻击（Denial of Service 拒绝服务攻击）

查明对手的证书
虽然使用HTTP协议无法确定通信方，但是如果使用SSL就可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。
证书由值得信任的第三方机构颁布，用于证明服务器和客户端是实际存在的。
另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方持有的证书，即可判断通信方的真实意图。
7.1.3无法证明报文完整性，可能已经遭到篡改
从某个 Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。 文件内容在传输途中可能已经被篡改为其他的内容。
像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack， MITM）。
不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。
可惜的是，用这些方法也依然无法百分百保证确认结果正确。因为PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。
7.2　HTTP+ 加密 + 认证 + 完整性保护 =HTTPS
7.2.1　HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS
在Web登录页面和购物界面等使用HTTPS通信。
当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏会出现一把锁。
7.2.2　HTTPS 是身披 SSL 外壳的 HTTP
通常HTTP直接和TCP通信，当使用SSL时，演变成先和SSL通信，再由SSL和TCP通信。
所谓HTTPS，其实就是身披SSL协议外壳的HTTP。用了SSL后，HTTP就拥有了加密、证书和完整性保护这些功能。

SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。
可以说，SSL是当今世界上应用最为广泛的网络安全技术。
7.2.3　相互交换密钥的公开密钥加密技术
SSL 采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。
加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密。
使用两把密钥的公开密钥加密
公开密钥加密使用一对非对称的密钥。 一把叫做私有密钥（privatekey），另一把叫做公开密钥（public key）。
HTTPS采用混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换， 那么有可能会考虑仅使用公开密钥加密
来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。
7.2.4　证明公开密钥正确性的证书
可证明组织真实性的EV SSL证书
用以确认客户端的客户端证书
认证机构信誉第一
由自认证机构颁发的证书称为自签名证书
7.2.5　HTTPS 的安全通信机制

步骤 1：客户端通过发送 Client Hello 报文开始 SSL 通信。报文中
包含客户端支持的 SSL 的指定版本、加密组件（Cipher
Suite）列表（所使用的加密算法及密钥长度等）。

步骤 2：服务器可进行 SSL 通信时，会以 Server Hello 报文作为应
答。和客户端一样，在报文中包含 SSL 版本以及加密组
件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤 3：之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

步骤 4：最后服务器发送 Server Hello Done 报文通知客户端，最初
阶段的 SSL 握手协商部分结束。

步骤 5：SSL 第一次握手结束之后，客户端以 Client Key Exchange
报文作为回应。报文中包含通信加密中使用的一种被称为
Pre-master secret 的随机密码串。该报文已用步骤 3 中的公
开密钥进行加密。

步骤 6：接着客户端继续发送 Change Cipher Spec 报文。该报文会
提示服务器，在此报文之后的通信会采用 Pre-master secret密钥加密。

步骤 7：客户端发送 Finished 报文。该报文包含连接至今全部报文
的整体校验值。这次握手协商是否能够成功，要以服务器
是否能够正确解密该报文作为判定标准。

步骤 8：服务器同样发送 Change Cipher Spec 报文。

步骤 9：服务器同样发送 Finished 报文。

步骤 10：服务器和客户端的 Finished 报文交换完毕之后， SSL 连接
就算建立完成。当然，通信会受到 SSL 的保护。从此处开
始进行应用层协议的通信，即发送 HTTP 请求。

步骤 11：应用层协议通信，即发送 HTTP 响应。

步骤 12：最后由客户端断开连接。断开连接时，发送 close_notify报文。

HTTPS也存在一些问题，就是当使用SSL时，他的处理速度就会变慢。
SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗 CPU及内存等资源，导致处理速度变慢。
不一直使用HTTPS
1. 与纯文本相比，加密通信会消耗更多的CPU及内存资源
2. 进行HTTPS通信，证书必不可少。而使用证书必须向认证机构CA购买。一般一年的授权需要 600人民币

第8章 确认访问用户身份的认证
.1 何为认证
为确认当前用户是否真的具有访问系统的权限，就需要核对“登陆者本人才知道的信息”， “登录者本人才有的信息”
● 密码：只有本人才会知道的字符串信息。
● 动态令牌：仅限本人持有的设备内显示的一次性密码。
● 数字证书：仅限本人（终端）持有的信息。
● 生物认证： 指纹和虹膜等本人的生理信息。
● IC 卡等：仅限本人持有的信息。
HTTP/1.1 使用的认证方式
BASIC
DIGEST
SSL
FormBase
8.2　BASIC 认证
8.3　DIGEST 认证
8.4　SSL 客户端认证
8.5　基于表单认证
8.5.1　认证多半为基于表单认证
8.5.2　Session 管理及 Cookie 应用

步骤 1： 客户端把用户 ID 和密码等登录信息放入报文的实体部分，
通常是以 POST 方法把请求发送给服务器。而这时，会使
用 HTTPS 通信来进行 HTML 表单画面的显示和用户输入
数据的发送。
步骤 2： 服务器会发放用以识别用户的 Session ID。通过验证从客
户端发送过来的登录信息进行身份认证，然后把用户的认
证状态与 Session ID 绑定后记录在服务器端。
向客户端返回响应时，会在首部字段 Set-Cookie 内写入
Session ID（如 PHPSESSID=028a8c…）。
你可以把 Session ID 想象成一种用以区分不同用户的等位号。
然而，如果 Session ID 被第三方盗走，对方就可以伪装成你的
身份进行恶意操作了。因此必须防止 Session ID 被盗，或被
猜出。为了做到这点， Session ID 应使用难以推测的字符串，
且服务器端也需要进行有效期的管理，保证其安全性。
另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事
先在 Cookie 内加上 httponly 属性。
步骤 3： 客户端接收到从服务器端发来的 Session ID 后，会将其作
为 Cookie 保存在本地。下次向服务器发送请求时，浏览器
会自动发送 Cookie，所以 Session ID 也随之发送到服务器。
服务器端可通过验证接收到的 Session ID 识别用户和其认
证状态。

通常，一种安全的保存方法是，先利用给密码加盐（salt） A 的方式
增加额外信息， 再使用散列（hash）函数计算出散列值后保存。但是我
们也经常看到直接保存明文密码的做法， 而这样的做法具有导致密码泄
露的风险。

salt其实就是由服务器随机生成的一个字符串，但是要保证长度足够长，并
且是真正随机生成的。然后把它和密码字符串相连接（前后都可以）生成散
列值。当两个用户使用了同一个密码时，由于随机生成的salt值不同，对应
的散列值也将是不同的。这样一来，很大程度上减少了密码特征， 攻击者也
就很难利用自己手中的密码特征库进行破解