CSRF：我可以使用cookie吗？

Question

将CSRF令牌放入cookie是否可以？ （并且在每种形式中，作为隐藏的输入，所以我可以检查它们是否匹配）当然我听到有人说这样做，打败了令牌的整个目的，虽然我不明白为什么。这对我来说似乎很安全。

如果它是安全的，它是否比将令牌放入URL的安全性更低？

还有其他方法吗？

我在哪里可以阅读更多关于这个主题的内容？

更新：到目前为止，没有人可以告诉我，如果Cookie方法仍然必须匹配攻击者无法获取的表单中的令牌，那么该方法是如何不安全的，除非他使用像XSS这样的另一个黑客，这是另一回事，但在使用cookie和url令牌之间仍然没有区别。

UPDATE 2 ：好的，好像有些着名的框架使用这种方法，所以应该没问题。感谢

Answer 1

使用Cookie有效，这是一种常见的做法（例如Django uses it）。由于同源策略，攻击者无法读取或更改cookie的值，因此无法猜出正确的GET / POST参数。

Answer 2

查看Encrypted Token Pattern，它允许无状态CSRF保护，而无需在服务器上存储令牌。

Answer 3

“CSRF有效，因为许多站点使用GET请求来执行命令。”，因此，许多站点不按预期使用GET方法，因为这些请求必须是幂等的：{{3} }。

“CSRF参数已存在于Cookie中，并随会话一起发送。”，那么如何？

当我们在隐藏的输入字段中设置令牌时，cookie仅用于具有令牌存储，作为DOM。一段javascript必须从此cookie获取令牌值，并将其设置为URL，请求正文或请求标头中的参数。它将在服务器上检查存储在会话中的值。这是处理CSRF令牌的Django方式。

由于跨域浏览器保护，Javascript无法从其他域访问cookie，因此我不知道恶意用户如何强迫某人在伪造请求中发送正确的令牌。使用XSS，是的，但XSS打败了常见的CSRF对策。

我更愿意澄清，因为我认为这是一个重要的问题而且不容易处理。

---

GET请求必须用于获取资源和/或显示其数据，不得用于更改其状态（删除，属性增量或任何更改） ）。

CSRF验证必须在服务器端完成，这似乎是显而易见的，但我把它作为提醒。 如果您观察到此建议，此方法不能成为攻击的载体。

Answer 4

如果您决定将CSRF令牌放入Cookie中，请记住将该Cookie标记为HttpOnly。如果您的站点存在跨站点脚本漏洞，则黑客无法读取CSRF令牌。您可以在任何现代浏览器控制台中使用命令console.log(document.cookie)检查JavaScript可以读取的cookie。如果您有会话cookie或其他敏感cookie，这些也应标记为HttpOnly。

进一步阅读：

https://www.owasp.org/index.php/HttpOnly

Answer 5

使用cookie会破坏CSRF的目的。原因如下：

CSRF之所以有效，是因为许多站点都使用GET请求来执行命令。所以说Bob有某种管理网络帐户，他已经登录了。有些请求可以像：

http://somesite.com/admin/whatever.php?request=delete_record&id=4

所以现在Bob被链接到攻击网站（有人试图弄乱他的数据）。然后攻击者在图像中加载上述URL，可能带有另一个ID并删除其他一些记录。浏览器加载它，因为Bob已经登录到他的管理站点，因此他有一个有效的会话。

CSRF寻求通过向事务添加安全参数来消除此问题。该参数应在每个请求上轮换，然后由浏览器重新发送。使URL看起来像这样：

http://somesite.com/admin/whatever.php?request=delete_record&id=4&csrf=<some long checksum>

这个想法是，现在攻击者必须猜测“一些长校验和”来创建攻击。如果该校验和在每个请求上旋转，那么它几乎是不可能的。

但是如果你将那个校验和存储在一个cookie中，你就会回到方块1.攻击者不再需要猜测它。他只是制作原始网址。 CSRF参数已存在于cookie中，并随会话一起发送。它并不能阻止不安全行为的发生。