【问题标题】:How storing JWT in-memory is not vulnerable to XSS?将 JWT 存储在内存中如何不受 XSS 攻击?
【发布时间】:2020-06-19 08:15:27
【问题描述】:

我正在关注这个tutorial on JWT using GraphQL

在那个教程中,

将其保存在 cookie 中怎么样?

在客户端创建 cookie 来保存 JWT 也会很容易出现 跨站脚本。如果它可以从您之外的 Javascript 在客户端上读取 应用程序 - 它可以被盗。您可能会认为 HttpOnly cookie(由 服务器而不是客户端)会有所帮助,但 cookie 是 容易受到 CSRF 攻击。重要的是要注意 HttpOnly 和 明智的 CORS 策略无法阻止 CSRF 表单提交攻击和 使用 cookie 需要适当的 CSRF 缓解策略。

所以作者将 JWT 保存在内存中(变量)。

但我在SO post 上读到 javascript 可以读取其他变量。

当攻击者可以在网站上运行 Javascript 时,就会发生 XSS。如果存在 XSS 漏洞,则攻击者可以读取/设置 cookie,通过读取 javascript 变量将用户的详细信息传输到攻击者服务器。那么,如何将 JWT 保存在内存中比存储在 Local Storage 或 cookie 中更安全?

我错过了什么吗? (我可能是因为我已经搜索过这个,但我在互联网上一无所获。)

【问题讨论】:

    标签: cookies jwt xss


    【解决方案1】:

    将 JWT 存储在内存中仍然会使它们容易受到 XSS 攻击,但它会使检索令牌变得更加困难。

    假设您在代码中使用了恶意库。如果您将令牌存储在 localStorage 中,则库可以将其中的所有内容都变笨,然后将其发送到其他地方。此攻击适用于任何将令牌存储在 localStorage 中的网站。如果您将令牌存储在内存中,则攻击者需要专门针对您的应用程序,因为需要额外的实现细节。

    我不建议将令牌存储在内存中,而是使用 HttpOnly cookie 来保护令牌免受 XSS 攻击。现在您只需要担心 CSRF,这可以通过简单地将 cookie 的 SameSite 属性设置为 Lax 来在现代浏览器中实现,或者您可以额外使用 CSRF 令牌。

    【讨论】:

    • 如果您的 auth api 和 FE 在不同的域上,SameSite 是不可能的/有帮助的
    • @gaurav5430 取决于,如果您的域结构良好,您可能具有以下内容。 example.com 上的前端和api.example.com 上的 api,然后您可以将 cookie 域设置为 .example.com,它将在两个域上都可用
    猜你喜欢
    • 2018-09-15
    • 2018-10-19
    • 2016-04-18
    • 2011-03-04
    • 2021-04-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多