CSRF 生成 token 的方式这样可以攻击吗？

Question

防御 CSRF 攻击，可以在表单页面的表单中生成一个 token，写在隐藏域中，同时保存在 session，使用 POST 方式，服务器端验证 token，那么如下这种方式攻击为什么不可以？ 在中间网站我请求两次，第一次通过 GET 方式请求这个表单页面从而获取 token，第二次带上这个 token 发起 POST 请求，这样不就成功伪装了吗？我这个想法应该有问题，但好像又可以，错在哪？

Answer 1

我自己回答一下：

首先，我说的第一步通过中间页用 GET 方法请求表单页面，获取到 token，这个没问题，第二步，把获取到的 token 用于动态构造的表单中发送 POST 请求，这个也可以实现，但是第二步请求 token 验证不会成功。

关键在于 session 机制，通过中间页去请求服务器页面，生成 token 并放在 session 中，这个 token 只对中间页 sessionid 标识有效，因为这个请求是中间页发起的，而不是用户 cookie 中的 sessionid，所以服务器在验证 token 的时候会发现不一致，用户 sessionid 对应的 token 的值，跟中间页 GET 请求页面生成的 token 值不一致。

Answer 2

CSRF的理解应该是没问题的

我说一下我的疑问点：
1.第一次通过 GET 方式请求这个表单页面从而获取 token
关注你的token获取，token本身是什么，就是服务器端对你这个访问者的一个标识。
表单提交页面，如果本身不需要你登录，那么本身就可以随便攻击，因为服务器端根本无法识别的你的身份。
那么如果你登录了，你通过使用这个token进行攻击，已经暴露你是谁。也就不存在伪装的意义。

所以就我理解，这个不能称为所谓的攻击，这能说模仿请求。。

我认为的攻击应该是这样的，敌人无法判断你是谁，然而你却能获取到资源。

Answer 3

在中间网站我请求两次，第一次通过 GET 方式请求这个表单页面从而获取 token，第二次带上这个 token 发起 POST 请求，这样不就成功伪装了吗？我这个想法应该有问题，但好像又可以，错在哪？

中间网站是什么？

如果是指中间人攻击，那么，你应该关注的是 HTTPS。CSRF 不处理中间人攻击。

如果是指第三方网站，那么，除非你的网站通过 Access-Control-Allow-Origin 头允许，否则第三方网站无法读取请求返回的内容（跟其它一些跨域请求的处理一样，能请求，但是未经允许不得访问），也就拿不到 token。

---

PS: 这么基础的问题，那么多回答，竟然只有一个稍微靠谱点的…………

Answer 4

首先，token 是在表单隐藏域中，第三方通过 get 方式如何获取？
其次，提供 token 的网站要避免通过 get 方式传递 token。

token 的方式不是绝对安全的，但是可以通过以下方式提升其安全性：

1. Referer 和 token 结合使用，服务端判断 token 之前，先判断 Referer 是否为本站；
2. 使用动态 token，限制 token 的时效性；

没有绝对安全的方法，但是可以尽量遵循安全的编程规范。

参考：CSRF 攻击的应对之道

Answer 5

回答在我的评论里，看看slim的插件slim-csrf

Answer 6

第一次你是获取不到token的，你会被直接导向到登录页面。

Answer 7

你把token这个键名也随机生成，然后位置也随机，反正不要让他抓取到，抓取到也要每次都改规则！！
其实你的多余的，他只是防止太简单的请求而已！！！！根本无法100%防止采集