图解HTTP总结（8）——确认访问用户身份的认证

Session 管理及 Cookie 应用

基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session（会话）。

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

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

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

向客户端返回响应时，会在首部字段Set-Cookie内写入SessionID（如PHPSESSID=028a8c...）。

你可以吧SessionID想象成一种用以区分不同用户的等位号。然而，如果SessionID被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止SessionID被盗，或被猜出。为了做到这点，SessionID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。

另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在Cookie内加上httponly属性。

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

不仅基于表单认证的登录信息及认证过程都无标准化的方法，服务器端应如何保存用户提交的密码等登录信息等也没用标准化。通常，一种安全的保存方法是，先利用给密码加盐（salt）的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。但是我们也经常看到直接保存明文密码的做法，而这一的做法具有导致密码泄露的风险。

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