我有点不清楚在使用纯 JavaScript 应用程序时如何保护（或保护）不记名令牌。
我知道当用户向服务器请求令牌时，它的有效期可能为 14 天或 24 小时。但是一旦用户拥有令牌，就没有简洁（可靠）的方法来保护它免受 XSS 或 CSRF 攻击（我错过了什么吗？）。
现在假设用户已登录到 Web 应用程序，并且浏览器拥有此令牌，有效期为 14 天。如果用户正在访问另一个尝试执行 XSS（或 CSRF）的 Web 应用程序，则令牌会暴露给第三方应用程序，并且此应用程序可以使用此令牌调用我的应用程序（？）
我尝试在线搜索，但没有具体的（或易于理解的）纯 js 应用程序以及如何保护令牌。或者在 js atm 中没有好的方法可以做到这一点。你只是希望（并祈祷）攻击不会在令牌的有效期内发生（即 14 天：|）？
欢迎对此提出任何想法或意见。
谢谢
编辑：它可能。不用说，但我们假设使用 SSL 证书。
【问题讨论】：
标签： security cookies oauth xss csrf
所以，一个非常快速的总结。发生 CSRF 是因为对 HTTP 端点的请求会自动包含 cookie（应该如此）以及服务器描述的所需标头，并且不需要用户进行物理操作。他们只需访问一个带有 CSRF 矢量的网页。
如果没有使用首先传递给客户端并返回到服务器以验证用户确实打算拨打电话的唯一“秘密”，则通常认为 CSRF 是可能的。一般来说，Web 浏览器正在塑造保护任何类型应用程序免受 CSRF 攻击的主要方法。 CSRF on OWASP
正如您所指出的，您使用不记名令牌（作为 HTTP 标头发送） - 但您仍然受到保护，因为默认情况下请求需要来自同一来源。如果服务器允许来自所有来源的调用，这些调用在 HTTP 标头中返回（它会告诉您用户的 Web 浏览器是否允许），那么在他们的头上就是 Same origin policy here。
至于 XSS，只要您的 cookie 至少具有“HTTP”标志，它们对用户访问的任何页面上的 javascript 代码都是不可见的。加上严格意义上的 XSS 向量，包括窃取您网站的 cookie，一般来说需要在您的网站上执行。无论如何，除非用户在您的网站上，否则我无法想到要窃取它们。如果您设置“安全”标志，这会更好，因为它也仅强制“服务器”，并确保仅在建立 TLS/SSL 连接时发送 cookie。 XSS on OWASP
以下是列出带有安全和 HTTP 标志的 cookie 的屏幕截图：
另外，请确保始终强制执行 TLS 连接，否则它们可能会成为对公共 WIFI 网络的 MITM（中间人）攻击的受害者，该攻击会强制协议降级为易受攻击的 SSL 的弱版本贵宾犬或根本没有。请阅读 HSTS，因为它肯定会加强我提到的所有内容，并真正有助于防止令牌被盗 HSTS OWASP 和 HSTS info wikipedia
【讨论】：