Security 我可以用饼干吗？
将CSRF令牌放入cookie中可以吗？（在每种形式中，作为一种隐藏的输入，因此我可以检查它们是否匹配，当然）我听到有人说这样做，超过了代币的全部用途，尽管我不明白为什么。对我来说似乎很安全 如果它是安全的，那么它的安全性是否比将令牌放入URL中的安全性低 还有其他方法吗 我在哪里可以阅读更多关于这个主题的文章 更新：到目前为止，没有人能告诉我cookie方法是如何不安全的，如果它仍然必须与表单中的令牌相匹配，攻击者应该无法获得，除非他使用另一种黑客，如XSS，这是另一回事，并且使用cookie和url令牌之间仍然没有区别Security 我可以用饼干吗？,security,cookies,csrf,Security,Cookies,Csrf,将CSRF令牌放入cookie中可以吗？（在每种形式中，作为一种隐藏的输入，因此我可以检查它们是否匹配，当然）我听到有人说这样做，超过了代币的全部用途，尽管我不明白为什么。对我来说似乎很安全 如果它是安全的，那么它的安全性是否比将令牌放入URL中的安全性低 还有其他方法吗 我在哪里可以阅读更多关于这个主题的文章 更新：到目前为止，没有人能告诉我cookie方法是如何不安全的，如果它仍然必须与表单中的令牌相匹配，攻击者应该无法获得，除非他使用另一种黑客，如XSS，这是另一回事，并且使用cookie
更新2：好的，看起来一些著名的框架使用了这种方法，所以应该没问题。谢谢使用cookie违背了CSRF的目的。原因如下： CSRF之所以有效，是因为许多站点使用GET请求来执行命令。假设Bob拥有某种管理web帐户，并已登录。可以提出如下请求：
http://somesite.com/admin/whatever.php?request=delete_record&id=4http://somesite.com/admin/whatever.php?request=delete_record&id=4&csrf=但如果你把校验和存储在cookie中，你就回到了第一步。攻击者不再需要猜测它。他只是创建了原始的URL。CSRF参数已经存在于cookie中，它将与会话一起发送。它不会阻止不安全行为的发生。使用cookies是有效的，并且是一种常见的做法（例如）。由于同源策略，攻击者无法读取或更改cookie的值，因此无法猜测正确的GET/POST参数。“CSRF工作，因为许多站点使用GET请求来执行命令。”因此，许多站点没有按预期使用GET方法，因为这些请求必须是幂等的： “CSRF参数已经存在于cookie中，并且它会随会话一起发送。”，那么如何发送呢 cookie只有一个令牌存储，当我们在一个隐藏的输入字段中设置令牌时，它就是DOM。javascript必须从这个cookie中获取令牌值，并将其设置为URL、请求正文或请求头中的参数。它将使用会话中存储的值在服务器上进行检查。这是Django处理CSRF令牌的方法 由于跨域浏览器的保护，Javascript无法从另一个域访问cookie，因此我不知道恶意用户如何强制某人在伪造的请求中发送正确的令牌。使用XSS，是的，但是XSS击败了常见的CSRF对抗 我更愿意澄清，因为我认为这是一个重要的问题，不太容易处理
GET request必须用于获取资源和/或显示其数据，不得用于更改其状态（删除、属性增加或任何更改）
CSRF验证必须在服务器端进行，这似乎很明显，但我把它作为一个提醒。如果您遵守此建议，此方法不会成为攻击的载体。请查看，它允许无状态CSRF保护，而无需在服务器上存储令牌。如果您决定将CSRF令牌放入cookie中，请记住将该cookie标记为
HttpOnlyconsole.log（document.cookie）HttpOnly如果说攻击者只需要原始URL，我不认为这是一个完美的答案：再说一遍，攻击者将如何使表单令牌和cookie令牌匹配？。如果我的站点易受XSS攻击，那完全是另一回事，我仍然不认为它会比在URL中使用令牌更不安全。如果攻击者可以通过XSS从表单获取令牌，那么他也可以从URL获取令牌。我错了吗？@HappyDeveloper-是的，CSRF也可以发生在POST上。GET更常见，因为它更容易。表单标记必须匹配cookie中显示的任何内容。所以攻击者不必做任何事情。他只是将请求发回，服务器就会读取cookie。@HappyDeveloper您不知道发生了什么。请阅读最基本的CSRF介绍，以及OWASP CSRF预防备忘表。@Cfreak同时，基于帖子的CSRF攻击也同样常见，并且很容易被利用。您只需调用
document.getElementById（1）.submit（）