网络安全 01 - Session Fixation

会话固定
固定的【会话标识符】（Session Identifier）造成的安全问题
即过于固定的 Session ID 机制

场景

【受害人】有一个银行账户，银行的网站是：http://www.bank.com/
【黑客】准备盗取【受害人】银行里的钱

场景 1：网站使用 URL 参数携带客户端生成的 Session ID

【黑客】发现 http://www.bank.com/ 的【会话标识符】为 URL 参数 sid
并且网站没有对【会话标识符】做安全校验
【黑客】向【受害人】发了一封电子邮件：“XX 银行新功能上线，欢迎使用，http://www.bank.com/?sid=abc123”
【受害人】点击链接进入 http://www.bank.com/?sid=abc123
页面提示登录，【受害人】正常登录
此时，【黑客】可以通过 http://www.bank.com/?sid=abc123 不受限制地访问【受害人】的账户

场景 2：网站使用 URL 参数携带服务端生成的 Session ID

【黑客】访问 http://www.bank.com/ 并查看返回的 sid
例如，服务器响应: Set-Cookie: sid=abc123
【黑客】向【受害人】发了一封电子邮件：“XX 银行新功能上线，欢迎使用，http://www.bank.com/?sid=abc123”
【受害人】点击链接进入 http://www.bank.com/?sid=abc123
页面提示登录，【受害人】正常登录
此时，【黑客】可以通过 http://www.bank.com/?sid=abc123 不受限制地访问【受害人】的账户

场景 3：网站使用 Cookie 携带的服务端生成的 Session ID

利用 Cookie 可以设置通配符来匹配子域名的特点来进行攻击

【黑客】注册了域名 good.bank.com，在这个域名下，【黑客】建了一个 Web 服务
【黑客】访问 http://www.bank.com/ 并查看返回的 sid
例如，服务器响应: Set-Cookie: sid=abc123
【黑客】更改自己服务器的数据库，配置 sid 为 abc123
【黑客】向【受害人】发了一封电子邮件：“XX 银行新功能上线，欢迎使用，http://good.bank.com/”
【受害人】访问 good.bank.com
【受害人】得到响应：Set-Cookie: sid=abc123 domain=.bank.com（这里的 sid 是黑客服务器根据数据库设置的）
【受害人】根据【黑客】站点引导，跳转到 http://www.bank.com/，页面提示登录，【受害人】正常登录

因为【受害人】和【黑客】浏览器中同一个 Cookie 通配符（即：顶级域名一样）下存的 sid 值一样
因此【黑客】向 http://www.bank.com/ 发起请求时，浏览器会携带这个带有 sid 的 Cookie
这样一来，【黑客】的 Cookie 就携带了和【受害人】一样的 sid，从而可以不受限制地访问【受害人】的账户

场景 4：受害人登录黑客的账户

【黑客】引诱【受害人】登录【黑客】的账号
在登录期间【受害人】输入的一些信息，【黑客】可以通过之后浏览自己账号的历史获取到

防护方案

场景 4 比较少见，可以通过业务流程设计来避免

前 3 个场景都可以通过如下方式进行防护：
在用户提交账号密码登录的请求中，后端在鉴权成功后，修改 Session ID
这样【黑客】无论通过何种方式获得的用户登录前的 Session ID，在用户登录后都会失效
具体实现可参考：Spring Security 02 - 鉴权 中的 “ 11. 会话管理 ”