按照我对 CSRF 攻击的理解,只要我在自己的 Ajax 请求的 HTTP Header 中添加一个自定义字段,然后服务器检验这个字段是否存在就可以识别是否是合法的请求。
这样,跨站的 Ajax 由于跨域限制无法请求,伪造的 POST 请求由浏览器生成,不会有自定义的 Header 字段。似乎就足以阻止 CSRF,还有什么攻击方式吗?当前这里讨论的前提是全站 HTTPS,没有 XSS。
按照我对 CSRF 攻击的理解,只要我在自己的 Ajax 请求的 HTTP Header 中添加一个自定义字段,然后服务器检验这个字段是否存在就可以识别是否是合法的请求。
这样,跨站的 Ajax 由于跨域限制无法请求,伪造的 POST 请求由浏览器生成,不会有自定义的 Header 字段。似乎就足以阻止 CSRF,还有什么攻击方式吗?当前这里讨论的前提是全站 HTTPS,没有 XSS。
1
justs0o Jul 2, 2019
HTTP Header 中添加一个自定义字段和一般验证 refer 来源没啥区别,都是可以伪造的
最优的还是 token 或者 session 来判断当前用户身份和敏感操作需要验证码 |
2
murmur Jul 2, 2019
这个 token 是用一次就失效的,当然要够随机
以前在各种漏洞多的时候是防 CSRF 的 现在还多了防机器人和爬虫的功能 |
3
AngryPanda Jul 2, 2019 via Android
@murmur 这个 token 并不是用过一次就失效的。
|
4
bluehr Jul 2, 2019
@AngryPanda csrf 的 token 不都是用一次就失效了吗,服务端只要校验过这个值,这个值就被置为失效
|
5
AngryPanda Jul 2, 2019 via Android
当然不是。这个 token 在一次会话内可以重复使用。
|
6
murmur Jul 2, 2019
@AngryPanda 跟恶心程度有关,正常来说不会被恶意猜出来伪造提交就算达到需求,但是现在多了防爬虫的功能
|
7
AngryPanda Jul 2, 2019 via Android
@murmur 不理解。
|
8
mcfog Jul 2, 2019 https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#use-of-custom-request-headers
TLDR:这个做法有很多优势,但已知挡不住 Flash,也容易被其他类似的技术绕过,不建议作为主要防御手段 |
9
GG668v26Fd55CP5W Jul 2, 2019 via iPhone
我觉得可以
|
10
pofeng OP @justs0o 在 HTTPS 的情况下,伪造者怎么拿到用户 cookie 中的 session 信息去伪造请求,并且请求中还带上自定义的 Header ?
|
12
Levi233 Jul 2, 2019
flash 也不能随便随便跨域啊,得看 crossdomain.xml 的,而且现在 2019 年还有哪几个浏览器支持 flash。。。楼主不用在意这个问题
|
13
seeker Jul 2, 2019
token 不能被猜到。一种方式就是服务端生成,如果你有其他方式也行。
|