对付 crsf 的关键在于让恶意网站无法伪造信息,那么为什么要那么复杂?

[petelin]

我知道现在的避免 crsf 做法,也看过 django 的中间件的实现.

但是,恶意网站所能做的事情很少啊,比如他是不能任意添加 HEAD 的,这是 cors 的限制,简单请求你只能自定义那几个方法,复杂请求更安全了,恶意网站都发不了请求. (这句话对吗?)

所以我们可以直接在后端验证一下有没有自定的 header, 对应的值对不对,注意这个是静态的 header,整个网站都一样的.

但是没人这么做过,应该是不对,所以请问各位那里错了?

[airyland]

后端直接发啊，哪有 cors 限制。。

[murmur]

最简单对付 crsf 不就一个 token 的事么 有那么复杂么 何况防重复提交的表单不考虑 crsf 也都加了 token 吧

[jugelizi]

cors 是浏览器的功能
谁知道万一浏览器厂商出个 bug 可以绕过呢
还是 flash 可没限制自定义 header

[mdzz]

用户输入是不可信的。—— 佚名（到底谁说的

[larry618]

@mdzz 佚名 ==> 沃 兹基硕德

[petelin]

@murmur token 是要生成的,我的问题是我们不需要生成,直接跟前端定义好一个就行.一直用一个就好.

[petelin]

@airyland 有后端无视你任何防御手段.

[ryd994]

@petelin WTF ，那叫什么 token ？
人家抓一下你源代码全都出来了

[ryd994]

@petelin 就算直接发请求也绕不过一次性 token 啊，用过就失效了，因为是在服务器上限制的
而 cors 用 curl 就能跳过

[petelin]

@jugelizi 这个解释比较合理...那要这么说的话,我们把 token 放在 cookie 里也不保险,万一浏览器有问题,恶意网站能拿到 cookie 里的值然后放在 post 中呢 /

[shiji]

难道不是 CSRF 么？楼主把二楼都给带顺拐了。

[murmur]

@petelin 所以 cookie 放在前台页面生成好不跟 cookie 啊

[glasslion]

crsf 主要防的的劫持 form 提交(xss), 而 表单提交是 无法设置 http header 的。

cors 和 csrf 有毛线关系

[falcon05]

csrf 处理 ajax 请求一般就是在 head 附一个特殊字段

[mdzz]

CRSF 全称 Cross Site Request Forgery ，跨站请求伪造。用我话说恶意网站 B 站在用户不知情的情况下操作了 A 站的用户资源状态。 —— 沃·兹基硕德

（该去看眼科了

[falcon05]

@falcon05 但 header 的这个字段是动态的，或者说有过期时间

[gamexg]

@glasslion +1
需要考虑哪个方案简单，哪个方案兼容性高。
在表单加一个隐藏字段轻松解决,为什么要自己构建 post 请求并添加 header ？
而且 header 兼容性并不好：
https://developer.mozilla.org/zh-CN/docs/Web/API/XMLHttpRequest/setRequestHeader

[petelin]

@falcon05 所以我的问题是他是静态的也可啊,非要费劲生成一个动态干嘛?

[petelin]

@gamexg 有道理,直接添加静态变化字段是很好的解决方案.
但是如果我提供的全是 api 呢,django 给出的方案是 cookie+post+token, 而我觉得直接在 ajax 提交的时候设置特殊 *静态 * HEAD, 服务器校验就好,即解决了问题,又不复杂.

[Mutoo]

“恶意网站 B ” 这个定义就很宽泛的，可以是一个你常去的公共论坛，你根本不会注意，然后某个帖子别人插入了一个 img （大部分论坛都允许的）。但是这个 img 的 url 是目标网站 A 的一个 GET 请求地址。一般人访问这个帖子什么也不会发生，但是如果是目标网站的管理员，并且是登陆状态。那么这个 GET 请求就可能触发相应的功能，达成 CRSF 。这个过程黑客只需要构造一个有效的 GET 请求，其它都不需要做，甚至不需要弄到 cookie 。

防 CRSF 的过程就是让黑客无法构造有效的 GET 请求，例子让 get 请求带上 token ，该 token 由服务端生成，并设置有效期。