Session Fixation session固定攻击

Session Fixation session固定攻击

参考 https://en.wikipedia.org/wiki/Session_fixation

• Session Fixation session固定攻击
  • 一、常见攻击场景
    • 1. 场景1 简单的攻击场景
    • 2. 场景2 使用服务器生成的sessionID
    • 3. 场景3 使用跨子域cookie攻击
  • 二、常见防御手段
    • 1. 不从 GET/POST 的变量中接受session的id
    • 2. 每次登录都更改sessionID
    • 3. 每次请求都生成一个session
    • 4. 将sessionID存储区HTTP cookie中
  • 三、总结

一、常见攻击场景

1. 场景1 简单的攻击场景

在这一场景中，假定sessionID是前端生成的。

假设Alice在银行 unsafe.example.com有个账户，Mallory想攻击他的账户。

• 步骤1：Mallory确定银行 unsafe.example.com接受任何sessionID，并且接受sessionID从URL的查询参数中传过来，并且没有安全检查。
• 步骤2：Mallory发送一封邮件给Alice，内容是 “嘿，看看这个，我们银行有一个很酷的新账户摘要功能，http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID”。
• 步骤3：Alice点击这一链接，然后正常登录，由于链接已经附带了sessionID，服务器不再生成，这时Mallory可以用这一sessionID掌握Alice账号的所有权限。

2. 场景2 使用服务器生成的sessionID

假定sessionID是后端生成，且同样后端接受sessionID从URL的查询参数中传过来，并且没有任何安全检查。银行网站为http://unsafe.example.com/

同样假设Alice在银行 unsafe.example.com有个账户，Mallory想攻击他的账户。

• 步骤1：Mallory登录银行网站并且登录后获取了一个sid。
• 步骤2：Mallory发送了一个邮件给Alice，包含了如下链接：“http://unsafe.example.com/?sid=123456”。
• 步骤3：Alice点击此链接，登录银行网站，由于链接带有固定的sid，服务器不会新生成一个sid，因此Mallory可以使用该sid拥有Alice账号的所有控制权

3. 场景3 使用跨子域cookie攻击

这就像跨站点 cookie，只是它不依赖于浏览器漏洞。相反，它依赖于这样一个事实，即通配符 cookie 可以由影响其他子域的一个子域设置。

• 步骤1：网站 www.example.com 将子域分发给不受信任的第三方。
• 步骤2：一个这样的第三方，Mallory，现在控制了evil.example.com，诱惑Alice访问他的网站。
• 步骤3：对evil.example.com的访问会在Alice的浏览器上创建一个对子域.example.com的session cookie。
• 步骤4：当Alice访问www.example.com时，这一个cookie将会随着请求被发送。正如cookie的规范所述，Alice将使用Mallory所掌控的evil.example.com的cookie。
• 步骤5：一旦Alice登录，Mallory将可以使用Alice的账号。

---

这三个场景最后都可以导致Mallory最后可以获得Alice账号的控制权，同时也可能有一个另外的攻击场景如下：

并不需要Alice登录，Mallory可以监控Alice并滥用Alice输入的数据。例如，Mallory可以通过以上攻击方式给Alice一个Mallory自己的已验证的session，这样Alice将使用Mallory的鉴权信息访问网站。这样一旦Alice决定要买点什么东西并输入了自己的银行卡信息，Mallory就能通过自己账号的历史信息收到这一银行卡信息。

这种类型的session固定利用与“经典”利用场景不同，因为它发生在应用程序的未经身份验证的部分或反转身份验证（攻击者登录受害者）。

二、常见防御手段

1. 不从 GET/POST 的变量中接受session的id

不从GET/POST变量中接受session的id，改为从body中接受。

2. 每次登录都更改sessionID

如果用户每次登录都会改变sessionID，这一攻击就可以很大程度上被避免。当受害者点击了攻击者的带有固定sessionID的链接时会登录，但由于每次登录都会改变sessionID，攻击者无法使用固定session进入受害者的账号。

3. 每次请求都生成一个session

4. 将sessionID存储区HTTP cookie中

三、总结

就目前的系统而言，就笔者了解，一般使用token机制而不使用session，token一般都不会从url参数，甚至不会从header中接受而是从body中接受。

如果系统session将从后端生成并且每次登录都会重新生成，且重大操作有验证码等二次校验，就可以屏蔽掉这一攻击。