协慌网

我正在编写一个应用程序（Django，它确实发生了），我只想了解 “CSRF 令牌” 实际上是什么以及它如何保护数据。

如果不使用 CSRF 令牌，发布数据是否不安全？

简单的跨站请求伪造（CSRF）

• 假设您当前登录到www.mybank.com
• 假设从mybank.com将（在概念上）请求http://www.mybank.com/transfer?to=<SomeAccountnumber>;amount=<SomeAmount> 。 （不需要您的帐号，因为您的登录名暗示了该帐号。）
• 您访问www.cute-cat-pictures.org却不知道这是一个恶意网站。
• 如果该站点的所有者知道上述请求的形式（简单！），并且正确地猜测您已登录mybank.com （需要运气！），则他们可以在其页面上包含诸如http://www.mybank.com/transfer?to=123456;amount=10000 （其中123456是开曼群岛帐户10000是您以前认为很高兴拥有的金额）。
• 您检索了该www.cute-cat-pictures.org页面，因此您的浏览器将发出该请求。
• 您的银行无法识别请求的来源：您的网络浏览器将发送请求以及您的www.mybank.com cookie，并且看起来完全合法。你的钱去了！

这是没有 CSRF 令牌的世界。

现在，使用CSRF 令牌获得更好的效果：

• 传输请求使用第三个参数扩展： http://www.mybank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795028841971 ://www.mybank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795095028841971。
• 该令牌是一个巨大的，无法猜测的随机数，当mybank.com为您提供服务时，它将包含在他们自己的网页上。每次他们向任何人提供任何页面时，情况都是不同的。
• 攻击者无法猜测令牌，无法说服您的 Web 浏览器将其交出（如果浏览器正常工作...），因此攻击者将无法创建有效请求，因为带有错误的令牌（或无令牌）将被www.mybank.com拒绝。

结果：您保留了10000货币单位。我建议您将其中一些捐献给 Wikipedia。

（你的旅费可能会改变。）

编辑评论值得阅读：

这将是值得一提的从脚本www.cute-cat-pictures.org一般不会有访问令牌从您的防 CSRF www.mybank.com因为 HTTP 的访问控制。对于一些不合理地发送标头Access-Control-Allow-Origin: *人来说，此说明很重要：* 对于每个网站响应，却不知道它的用途，只是因为他们不能使用其他网站的 API。

是的，帖子数据是安全的。但是该数据的来源不是。这样，在浏览攻击者的网页时，有人可以诱骗 JS 用户登录到您的站点。

为了防止这种情况，django 将在 cookie 和表单数据中发送一个随机密钥。然后，当用户 POST 时，它将检查两个密钥是否相同。万一被用户欺骗，第三方网站将无法获取您网站的 Cookie，从而导致身份验证错误。

该网站在制作表单页面时会生成一个唯一的令牌。需要此令牌才能将数据发布 / 获取回服务器。

由于令牌是由您的网站生成的，并且仅在生成带有表单的页面时提供，因此其他网站无法模仿您的表单 - 他们没有令牌，因此无法发布到您的网站。