gab*_*ssi 5 javascript cookies csrf owasp jwt
我想从Stormpath帖子中对JWT令牌和CSRF提出疑问,解释将JWT存储在localStorage或cookies中的优缺点.
[...]如果你使用JS从cookie中读取值,这意味着你不能在cookie上设置Httponly标志,所以现在你站点上的任何JS都可以读取它,从而使它完全相同的安全性 - 作为在localStorage中存储内容的级别.
我试图理解为什么他们建议将xsrfToken添加到JWT.是不是将JWT存储在cookie中然后将其解压出并将JWT放在HTTP头中并根据HTTP头验证请求与Angular的X-XSRF-TOKEN完成相同的操作？如果您根据标头中的JWT进行身份验证,则其他域无法代表用户发出请求,因为其他域无法从cookie中提取JWT.我不了解JWT中xsrfToken的目的 - 也许它只是一个额外的防御层 - 这意味着攻击者必须在您的站点上拥有受损的脚本,并且当时CSRF必须是用户.所以他们必须以两种方式击中你以便能够进行攻击.
帖子在这个答案中链接说:
最后一件事是确保您对每个HTTP请求都有CSRF保护,以确保启动对您站点的请求的外部域无法正常运行.
[...]然后,在每次进入服务器的请求中,确保您自己的JavaScript代码读取cookie值并将其设置在自定义标头中,例如X-CSRF-Token,并验证服务器中每个请求的值.外部域客户端无法为您的域的请求设置自定义标头,除非外部客户端通过HTTP选项请求获得授权,因此任何CSRF攻击尝试(例如在IFrame中,无论如何)都将失败.
即使他们可以设置自定义标头,他们也无法访问存储JWT令牌的cookie,因为只有在同一域上运行的JavaScript才能读取cookie.
唯一可行的方法是通过XSS,但如果存在XSS漏洞,JWT中的xsrfToken也会受到影响,因为在可信客户端域中运行的恶意脚本可以访问cookie中的JWT,并在请求中包含xsrfToken的标头.
所以等式应该是:
如果客户端和服务器在不同的域中运行,则服务器应发送JWT,客户端应使用JWT创建cookie.我认为这个等式对这种情况仍然有效.
更新: MvdD同意我的意见:
由于浏览器不会自动将标头添加到您的请求中,因此它不容易受到CSRF攻击
我是Stormpath Blog Post的作者.在JWT中存储XSRF令牌并不是它在JWT中的存在,而是它在cookie中.cookie应该是httpOnly,因此您无法从Javascript中读取它.
现在,我认为引起一点混乱的一点是我谈论角度的地方.Angular设置它只是XSRF cookie(它不是httpOnly)在请求时将它放入标题(这只能通过同一域上的javascript完成).这些不是相同的cookie.
如果您考虑在应用程序中实现XSRF支持,那么已经完成了存储服务器端状态和存储XSRF的点.将它存储在httpOnly cookie中是关于使用XSRF进行无状态处理.在这里,您将验证JWT签名,从索赔中获取XSRF,并将其与标头进行比较.
您的问题的答案是,您不需要在您的服务器上存储状态.
我的理解是：
您的JWT受到保护，防止其在XSS中被盗，并且免受XSRF的保护。XSS仍可以在您的浏览器上执行，但只能对该浏览器中的会话造成损害。最终，您不能阻止某人编写只在您的浏览器上运行的非常详细的脚本，因此Web开发人员仍然需要传统的安全措施来防止XSS。