1
binux 2017-08-15 06:30:21 +08:00 via Android
然而 V2EX 现在的 csrf 不需要 js
|
2
zjsxwc 2017-08-15 06:33:55 +08:00 via Android
我觉得如果不考虑 ie6 这种老浏览器,其实上 https 与校验 referer 就能防御 csrf,没必要用 csrf token。
|
3
wenzhoou 2017-08-15 07:56:01 +08:00 via Android
5 年前的帖子。有错误啊。referer 主流的浏览器都能禁止的。referer 伪造比较容易,这条路我认为走不通。token 才是正确解决方式。楼主说 local storage,那不是特意把本来隐藏起来的东西,公开给所有人看吗?这样真的好吗?
|
4
caomu 2017-08-15 08:35:35 +08:00 via Android 1
v 站的 csrf 很有毒,而且 ajax 还照样返回正常。。。强迫我每次 ajax 操作都要手动刷新一次看结果,然后现在我都不后台多开帖子了,看完一个后退再看另一个。。。真希望能改进一下。。。
|
5
zjsxwc 2017-08-15 08:40:37 +08:00
|
6
zjsxwc 2017-08-15 08:53:09 +08:00
@autoxbc
>> 2. 因为写数据相比读数据是个低频行为,所以可以设立单独的 updateToken 方法,每次写数据操作,先 ajax 一个 token,服务器根据用户当前是否合法登录,决定是否返回有效 token。获取到 token 后,附加到写数据函数中。 你如果一定要使用 csrftoken,那么必须每个页面都是独立的 token,如果像你说的提供一个获取最新 csrftoken 的接口,来实现共用一个最新的 csrftoken 的话,你这个获取 csrftoken 的接口本身就有问题了,如何保证不被恶意跨域获取最新 csrftoken 呢?于是这种 csrftoken 方式就完全没有意义了。 |
7
honeycomb 2017-08-15 09:58:17 +08:00 via Android
@zjsxwc 我们一般会增大 referer 的粒度,或是不信任的情况下完全禁用 referer,以及 url 上的如 utm 的尾巴。
毕竟网站不需要知道用户从哪里来,或是要去哪里。 |
8
keakon 2017-08-15 10:18:14 +08:00 2
印象中 V2EX 应该是用 Tornado 实现的,默认的 csrfToken 是保存在 cookie 中的,服务端并不保存,而是检查 POST 的数据是否和 cookie 中一致。至于每个页面都更新 csrfToken,则不是 Tornado 干的。
|
9
cgb1021 2017-08-15 10:32:36 +08:00
2 young 2 simple
|
10
vjnjc 2017-08-15 10:56:16 +08:00
没有还原你说的发送感谢失败。。。。
|
12
autoxbc OP @zjsxwc #6
token 捆绑到用户而不是页面,第三方跨域取的 token 不是用户的 token,诱骗用户做取 token 的动作,得到的数据第三方也拿不到。可以仔细读帖子中的介绍文章。 |
14
autoxbc OP |
16
neilwong 2017-08-15 17:36:59 +08:00
我在想会不会有 xss+csrf 的混合型攻击,先 xss 获取到 csrfToken,再在自己页面上伪造提交,可能需要钓鱼链接支持才能实现吧
|
17
ctsed 2017-08-15 18:12:52 +08:00 via Android 1
其实只考虑防 csrf,token 复用也没事
|