我阅读了一些关于SPA应用程序中'JWT'安全性的文章，但对它容易受到多种类型的攻击感到困惑，而且直觉上很难掌握和设置。
据我所知，这整个事情与用户友好的安全性是关于一个用户保持登录，即使在浏览器重新启动，并仍然受到保护，从CSRF攻击。
我读过一些疯狂的方法，使用localStorage、cookies或内存中的值，以及在cookie上设置一些标志（如httpOnly），在浏览器中设置一些头，如果设置不正确，则容易受到XSS或CSRF等攻击。
因此，我的问题是以下安全方案是否有效？
1.将JWT标记存储在用户设备上的任何位置（localStorage、cookie等）（作为公共信息，任何人都可以读取）
1.后端将在每个请求上返回一个反CSRF报头
1.应用程序每次都会在内存中存储并刷新头值，并连续发送以证明是最初登录的用户
1.攻击者最终可能会获得JWT和/或尝试一些XSS或CSRF，但这是无用的，因为他不知道反CSRF头值
(Note使用这种方法，我基本上认为JWT标记表示身份验证，CSRF头表示授权。）
1条答案
按热度按时间avkwfej41#
你问题答案是否定的。
如果我设法在你的网站上做一个XSS，我将可以访问你的javascript可以访问的一切，包括CSRF令牌和JWT。是你的javascript将运行我的恶意javascript，这意味着我可以访问你的一切。
作为会话跟踪器的JWT令牌从很多Angular 来看都是非常糟糕的。Cookie自Netscape在90年代末创建以来就一直存在。它们已经通过一些安全特性得到了增强，如
HttpOnly标志等，而这些特性是JWT所没有的。如果您有服务器到服务器的无状态通信，那么JWT是很好的，因为您可以包括声明，声明添加了额外的信息，这样服务器就不需要对例如发布者
/userInfo端点进行额外的调用。服务器到服务器的通信通常也在安全网络中进行，因此令牌窃取或MITM的风险降低。
安全性是很难的，比许多人想象的要难得多，没有一个“简单的解决方案”，你需要保护你的网站免受多种不同的攻击，以及这些攻击的组合。
你永远不应该建立自己的自定义解决方案，因为总有更聪明的人可以打破自定义解决方案。
你应该经常查阅OWASP Cheat Sheet series，它试图收集你在构建现代网页时应该考虑的一切。