rest - 防止 CSRF 和 XSS(哈希 + 加密)

Question

安全。今天，如果没有适当的安全性编程到互联网上，任何应用程序都无法在互联网上生存 - 无论是开发人员使用的框架，还是开发人员自己。我目前正在开发一个 RESTful API 以使用 Bearer token 身份验证，但一直在阅读有关 XSS 和 CSRF 攻击的信息。

问题一)根据我的阅读，如果 token 存储在浏览器的 localStorage/sessionStorage 而不是 cookie 中，则使用基于 token 的身份验证的 RESTful API 的应用程序容易受到 XSS 而不是 CSRF 的攻击。这是因为，要使 CSRF 工作，应用程序必须使用 cookie。我对么？

但是现在 token 存储在 localStorage/sessionStorage 中，应用程序变得容易受到 XSS 攻击。如果应用程序的任何部分没有清理输入(例如，Angular 输入由框架清理，但我使用的某个 3rd 方库可能默认不清理输入)，那么攻击者可以注入(inject)恶意代码窃取其他用户的 token ，然后通过模拟他们发出经过身份验证的请求。

问题2)在使用 RESTful API 的应用程序中，有一种方法可以防止这两种攻击。我遇到了this post .那篇文章的要点是，在用户登录并请求不记名 token 时，让服务器也返回一个 httpOnly cookie，例如，CSRFProtectionCookie .我相信本文中的解决方案非常强大，并提供了强大的保护。再说一遍，我说的对吗？你有什么看法？

我的应用程序和我在上面帖子中提到的方法的版本

上面帖子中提到的方法需要我坚持 CSRFProtectionCookie在某种数据库中。我不想那样做。我不希望每次向 API 发出经过身份验证的请求时都会访问数据库。相反，我能做的是:

登录

用户使用用户名和密码向 token 端点发送 POST 请求

授权服务器验证用户凭据并开始使用某些声明构建 JWT。

作为 JWT 构建的一部分，它还会生成一个随机字符串 哈希 它，并将其添加为，例如，csrf向 JWT claim 。

此外，接下来服务器设置 httpOnly名为 XSRF-TOKEN 的 cookie其值为相同的随机字符串，但 加密 这次。

将响应返回给浏览器。浏览器获取不记名 token 作为响应正文和 XSRF-TOKEN cookie 已设置。

认证请求

应用程序通过将 JWT 不记名 token 添加为 Authorization 来调用经过身份验证的端点标题。浏览器会自动发送 cookie。

服务器解密 cookie 以获取纯文本。然后，服务器使用 JWT 中存在的哈希验证此纯文本。

如果匹配，请继续请求。否则，返回未经授权的响应。

我认为这可以同时防止 CSRF 和 XSS。因为 token 和 cookie (httpOnly) 都需要进行经过身份验证的请求。

问题 是的，这消除了将任何内容持久化到数据库的需要(或者是吗？我错过了一些漏洞吗？)。但是在每个用户请求上解密和验证哈希的开销是多少？它是否比数据库 I/O 开销更大？此外，欢迎对这种方法或其他方法提出任何其他建议!

谢谢 :)

Answer 1

回答问题 1

From what I've read, I see that applications consuming RESTful APIs that use token-based authentication are vulnerable to XSS and not CSRF if the token is stored in localStorage/sessionStorage of the browser instead of in cookies. This is because, for CSRF to work, the application must use cookies. Am I correct?

或多或少是正确的。仅使用 cookie 进行身份验证且没有任何 CSRF 保护的应用程序将容易受到 CSRF 的攻击，因为 cookie 会自动包含在所有请求中。

But now that the tokens are stored in the localStorage/sessionStorage, the application becomes vulnerable to XSS attacks.

并不是应用程序易受 XSS 攻击，而是身份验证 token 易受 XSS 攻击。如果您的身份验证 token 作为 http-only 发送，然后 JavaScript(以及 XSS 攻击)无法读取该值。
回答问题 2
我认为这篇文章很好地解释了如何使用 session cookie 和 CSRF token 。让我试着总结一下这篇文章，因为它有点长:

使用 http-only cookie(理想情况下还有 secure——作者没有提到——这会阻止浏览器在 http 请求上发送 cookie，只有 https 请求)作为 认证 token 。通过这种方式，cookie 无法被 JavaScript 读取，因此无法在 XSS 攻击中被窃取。

使用 session 存储来存储 CSRF保护 token 。这里的好处是一些 JavaScript 代码必须读取该值并将其放入请求中。在某些第 3 方上运行的恶意代码，受感染的站点将无法从本地存储读取 CSRF token ，因此将无法创建有效请求。

本文还详细介绍了如果您的静态资源位于与 REST 端点不同的域中，如何设置跨域 header 。
但是，您的方法与文章所说的相反。您将身份验证 token 放入 localStorage 并将 CSRF token 放入 cookie。我建议将其翻转过来，因为身份验证 token 比 CSRF token 更重要，并且 http-only secure对于坏人来说，cookie 比 localStorage 更难获得。
对您的方法的评论

The approach mentioned in the post above requires me to persist the CSRFProtectionCookie in a database of some sort. I do not want to do that. I do not want the database to be hit every time a authenticated request is made to the API.

在这里，您正在沿着一条好路思考。您所描述的将被称为“无状态 CSRF token ”。
您对“经过身份验证的请求”的处理方法看起来不错。我不完全确定您是否需要加密 CSRF token 值，但这并没有什么坏处。

this eliminates the need to persist anything to the database (or does it? Am I missing some loophole?)

你是对的，没有漏洞。

But what is the overhead of decrypting and verifying hashes on every user request? Is it more overhead than database I/O?

I/O 通常比 CPU 密集型计算慢得多，即使对于加密之类的东西也是如此。也就是说，如果你真的担心它，你就必须测量(当然，说起来容易做起来难)。
最后的想法...
请记住，通过将 CSRF token 存储在 JWT 声明中，CSRF token 将与 JWT token 一样有效。即使您向客户端发送新的 JWT token ，旧 token 和 CSRF token 仍然有效。对于短期 token (比如 10-60 分钟)来说，这不是问题，但是将 CSRF token 存储在服务器端某处的好处之一意味着您可以拥有一次性 token 用于超敏感操作。 (此外，如果您需要撤销尚未过期的 JWT token ，您还需要将该状态存储在服务器端的某个位置。但现在我们掉进了另一个兔子洞……)
真的没有特定的框架可以完全防止 XSS 漏洞，因为它们可以以多种不同的方式表现出来。也就是说，您的网络应用程序可以使用 Content-Security-Policy header 有助于防止 XSS 攻击。 CSP header 可用于告诉浏览器允许从哪些域加载资源(例如 JavaScript 文件)。它甚至可以用来阻止内联 JavaScript 运行(这是 XSS 的主要攻击媒介之一)。