security - 保护 oauth 承载 token 免受 JavaScript 应用中的 XSS、CSRF 等攻击

Question

我有点不清楚如何在使用纯 JavaScript 应用程序时保护(或保护)不记名 token 。

我知道当用户向服务器请求 token 时，它的有效期可以为 14 天或 24 小时。但是一旦用户拥有 token ，就没有一种简洁(有保证)的方法来保护其免受 XSS 或 CSRF 攻击(我是否遗漏了什么？)。

现在假设用户已登录 Web 应用程序，并且浏览器具有此 token ，该 token 的有效期为 14 天。如果用户正在访问另一个尝试执行 XSS(或 CSRF)的 Web 应用程序，则 token 将暴露给第三方应用程序，并且该应用程序可以使用此 token 调用我的应用程序(？)

我尝试在网上搜索，但没有任何关于纯 js 应用程序以及如何保护 token 的具体内容(或易于理解的内容)。或者在 js atm 中没有好的方法来做到这一点。您只是希望(并祈祷)攻击不会在 token 有效期内(即 14 天:|)发生？

欢迎对此提出任何想法或意见。

谢谢

编辑:有可能。不言而喻，但我们假设使用 SSL 证书。

Answer 1

所以，这是一个非常快速的总结。发生 CSRF 是因为对 HTTP 端点的请求自动包含 cookie(理应如此)以及服务器描述的所需 header ，并且不需要用户实际执行某些操作。他们只需访问带有 CSRF 矢量的网页即可。

如果不使用首先传递到客户端并返回到服务器的唯一“ secret ”来验证用户确实打算进行调用，则通常认为 CSRF 是可能的。一般来说，Web 浏览器正在塑造任何类型应用程序防范 CSRF 的主要方法。 CSRF on OWASP

正如您所指出的，您使用不记名 token (作为 HTTP header 发送) - 但您仍然受到保护，因为默认情况下请求需要源自同一来源。如果服务器允许来自所有来源的调用，这些调用会在 HTTP header 中返回(它告诉用户的 Web 浏览器是否允许)，那么在他们的头上就是 Same origin policy here .

对于 XSS，只要您的 cookie 至少具有“HTTP”标志，它们对于用户访问的任何页面上的 javascript 代码都是不可见的。另外，严格来说，XSS 向量(包括窃取您网站的 cookie)通常需要在您的网站上执行。除非用户实际访问您的网站，否则我无法想到如何窃取它们。如果您设置“安全”标志，效果会更好，因为它也仅强制“服务器”，并确保仅在建立 TLS/SSL 连接时才发送 cookie。 XSS on OWASP

以下是列出了安全和 HTTP 标志的 cookie 的屏幕截图:

此外，请确保始终强制执行 TLS 连接，否则它们可能会成为公共(public) WIFI 网络上 MITM(中间人)攻击的受害者，该攻击会强制协议(protocol)降级为易受攻击的 SSL 弱版本 Poodle 或根本没有。请阅读 HSTS，因为它肯定会强化我提到的所有内容，并真正有助于防止 token 被盗 HSTS OWASP和 HSTS info wikipedia