【问题标题】:Should session id be encrypted in cookie?会话 ID 是否应该在 cookie 中加密?
【发布时间】:2018-11-06 08:10:43
【问题描述】:

在单页应用中:

我想使用 httpOnly/Secure cookie 来验证 Bearer 令牌没有从本地存储中被盗。

换句话说,cookie 和不记名令牌必须在被认为有效之前被出示并交叉检查。

例如:

用户使用用户名/密码成功登录。

创建了一个 Jwt Bearer 令牌,其中包含 12345 的会话 ID。

此外,cookie 被格式化为 jwt 并签名并包含会话 ID 12345 的声明。

现在,当使用令牌和 cookie 发出 ajax 请求时,会比较会话 ID。如果它们匹配,则请求得到满足。

这安全吗?还是应该在 cookie 或 token 上加密 Session Id?

【问题讨论】:

  • “安全”不是布尔值。
  • @Flimzy,我不太关注你。有没有更好的方式来表达这个问题?
  • 没有什么是“安全的”或“不安全的”。它不是一个布尔值。某些东西在一定程度上是安全的,并且对于特定的攻击向量。
  • 如果你能负担得起将令牌放在 httpOnly cookie 中,为什么还要在 localStorage 中使用它?
  • 因为单页应用需要token中的信息才能运行。它无法读取 httpOnly cookie。通过两者,应用程序获取数据,但 httpOnly cookie 确认它是有效的。

标签: security jwt session-cookies


【解决方案1】:

根据您告诉我们的内容,您的设置可能是安全的,也可能不是。您需要提供更多详细信息才能让我们确定。

例如,根据您告诉我们的内容,您基本上是在向用户发出两个不同的持有者令牌,说“允许此令牌的持有者访问会话 12345”,其中一个令牌存储在httpOnly cookie 和 LocalStorage 中的另一个,并且仅在两个令牌都存在且有效且彼此匹配时才允许访问。

但是,您的描述没有明确说明 LocalStorage 令牌是否也可以作为 cookie 令牌有效,反之亦然。如果可以的话,捕获其中一个令牌的攻击者可以简单地在同一个 Ajax 请求中提交相同的捕获令牌两次,一次在 cookie 中,一次在请求参数中,因此看起来是有效的。

此外,仅仅检查请求中的两个令牌是否不相同可能是不够的,因为攻击者可能能够捕获例如同一会话的两个不同的有效 LocalStorage 令牌。相反,您需要做的是在构成令牌的签名数据中包含某种令牌类型标识符来防止此类攻击(例如,仅type: "cookie"type: "param")并验证每个令牌的类型实际上与它们呈现给服务器的方式相匹配。

或者,您也可以为 cookie 令牌和参数令牌使用两个不同的签名密钥;这样,将令牌从 LocalStorage 复制到 cookie 或反之亦然会自动使签名无效。

也就是说,只要您以某种方式确保每种类型的令牌仅在通过适当的渠道呈现时才有效,那么您的设置至少不低于比简单地使用单个令牌安全。它还应该防止某些类型的附加攻击,例如 CSRF 攻击(它可以允许攻击者使用合法用户的 cookie 发出恶意请求)和某些类型的 JS 注入攻击(这可能会危及用户的 LocalStorage,但不会危及他们的 cookie )。

但是,我们无法真正判断这些攻击是否对您的应用程序构成相关威胁,以及是否存在您的方案不足以防御的其他攻击。特别是,虽然您的方案应该足以抵御破坏 LocalStorage 的攻击,但值得注意的是,大多数可以做到这一点的攻击也允许攻击者做其他事情,例如自己制作来自用户浏览器的 Ajax 请求(这会阻碍您的计划)。

也就是说,至少您的方案(如果实施正确)提供了 CSRF 保护,这是一件有用的事情。它是否提供更多的东西是另一回事。

(在任何情况下,只要攻击者仅通过知道会话 ID 就不能做任何恶意的事情,通常就不需要加密会话 ID 或包含它的任何令牌。如果他们可以,那么拥有会话 ID无论如何,像“12345”这样的想法是个坏主意,因为攻击者很容易尝试从 0 到 999999 的所有会话 ID。)

【讨论】:

  • 非常感谢。非常有帮助。是的,我将包含一个类型标识符。感谢您提供有关加密的说明。就我而言,我认为没有必要。还有一点,攻击者仍然可以从用户的浏览器中发出 Ajax 请求。这个角度我之前没有想过,会考虑的。
猜你喜欢
  • 2015-05-02
  • 2017-05-30
  • 1970-01-01
  • 2013-08-29
  • 2019-09-29
  • 1970-01-01
  • 2011-10-10
  • 2011-04-30
  • 1970-01-01
相关资源
最近更新 更多