拉拉维尔 等框架要求您将csrf令牌放在您的HTML中。
但是,与此同时,laravel默认使用 VerifyCsrfToken 中间件,该中间件在每个响应上都会自动创建带有csrf令牌的 X-XSRF-TOKEN cookie。这个cookie用于ajax请求,例如,它是axios头部的 自动添加 。
VerifyCsrfToken
X-XSRF-TOKEN
我想知道为什么需要将csrf令牌添加到每个HTML表单中。为什么不能仅仅使用已经存在的 X-XSRF-TOKEN cookie来验证csrf令牌。我知道存在同一个网站cookie的问题,如果您的csrf cookie设置为 lax 或 none ,那么cookie将从外部站点发送到我的站点。但是,这个问题可以通过将相同的站点设置为 strict 来解决,这样就不需要在每个表单上设置csrf令牌了,这样做和记住都有点烦人。
lax
none
strict
对于为什么我们不能使用 strict cookie来验证csrf令牌,是否存在一些安全问题?
发布于 2022-11-12 15:00:15
X令牌保护用户避免不必要的修改请求的执行,这对用户的副作用(他们对服务器或数据库所做的更改)很感兴趣,而不是针对他们的响应,由于 CORS 协议,攻击者无论如何都无法读取这些响应。
同一个站点cookie甚至可以防止导航请求的执行,导航请求不会改变服务器上的任何内容,而只会读取数据(包括用于随后修改请求的X令牌),然后这些数据将显示在HTML页面中。例如,如果stackoverflow.com具有相同的站点会话cookie,您将无法通过邮寄链接导航到 这个StackOverflow问题 的the邮件站点,并立即单击以向上投票,因为会话cookie将不包括在导航请求中,因此一开始不会登录。
发布于 2022-05-13 06:51:13
SameSite cookies确实提供了对CSRF攻击的重要保护。但是,最好的办法是采取明确的反措施--由反CSRF令牌提供。
首先,SameSite使用了“可注册域”的概念,因此它不会保护您免受 子域劫持 的攻击。
最后,对于这些主题,我非常推荐一本优秀的书 Api在行动中的安全性 --它们在第4章中讨论了CSRF和相关主题。
发布于 2022-11-09 09:47:37
通过cookie验证csrf令牌是没有意义的。这就是我们正在努力解决的问题。如果将csrf令牌作为cookie发送和验证,也可以发送它,并在跨站点请求中发送。但是在执行跨站点请求时,据我所知,攻击者不能用js读取该cookie并将其放入表单中,只有我们可以使用js访问该cookie。这是因为当我们设置cookie时,我们指定了域属性,并且只能在特定的域上用js读取该cookie。这就是为什么这个cookie不仅仅是http的原因,也是为什么我们在表单中包含它的原因。
https://stackoverflow.com/questions/72223272