这是一个创建于 2871 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近集团换了一个安全公司为网站做渗透测试，
出了一份漏洞报告：
大体内容为，黑客可以用 CSRF 方式修改用户个人信息，条件系黑客写好 post form 保存为 test.html 并把 test.html 存放在被攻击者本机，诱导被攻击者打开该文档 或将 test.html 放在我司域名服务器，诱导客户点击
我司网站已经配置了全局 csrf 过滤器，检查 refer 字段匹配白名单
本地首次请求 refer 为空，可以成功 在我司域名服务器 refer 合法，可以成功
但是？？？ 黑进客户电脑 /我司服务器 这种情况来说一个修改个人信息漏洞 没事吧？？
第 1 条附言 2018-02-07 09:35:33 +08:00
以上问题已在 csrf 过滤器之后曾加 session token 校验
但是 csrf 的经典场景不应是 a 站内嵌 b 站 post，用户登录 b 站并打开 a 站，导致被攻击？
我的情景是：用户没有打开任何域名页面，只是打开了 file:///C:/Users/Admin/Desktop/test.html
但是 csrf 的经典场景不应是 a 站内嵌 b 站 post，用户登录 b 站并打开 a 站，导致被攻击？
我的情景是：用户没有打开任何域名页面，只是打开了 file:///C:/Users/Admin/Desktop/test.html
第 2 条附言 2018-02-07 09:37:37 +08:00
另一个场景 黑客攻破我司服务器，放置一个内嵌 post 的 html，地址为：www.我司域名.cn/test.html 用户点击被攻击
 | 1 yulitian888 2018-02-06 12:27:07 +08:00 如果是办公环境的话，邮件 /QQ 诱导点击的成功概率并不低啊，真的不要高估工作人员的素质 |
 | 2 xomix 2018-02-06 12:28:15 +08:00 所以后台要发 token ……这样你随便 post，你有能用的 token 算我输。 |
 | 3 FONG2 OP @yulitian888 如果客户随便打开陌生文件，这个安全危害更大啊 |
 | 4 qlin 2018-02-06 12:35:02 +08:00 简单的做个跨资源访问限制 + content-type 限制，就差不多了 |
| 5 FONG2 OP @xomix 是的，像这种无风险业务我觉得屏蔽 get，屏蔽跨域 post，保证客户不是被动发起非法请求，至于关键业务我们是有二次鉴权的。 |
 | 6 leir 2018-02-06 12:45:25 +08:00 via Android 为啥不使用 csrf token ？ |
 | 7 Zzzzzzzzz 2018-02-06 12:49:06 +08:00 "本地首次请求 refer 为空，可以成功 在我司域名服务器 refer 合法，可以成功" 如果这种方式能成功 通过诱导用户访问不发送 referer 的 ssl 页面用 js 自动提交不也可以么 |
 | 8 caola 2018-02-06 12:51:56 +08:00 为啥不使用 csrf token ？ +1 |
 | 9 40huo 2018-02-06 12:55:46 +08:00 via Android 这是标准的 csrf |
 | 10 jimrok 2018-02-06 13:01:28 +08:00 发一个够劲爆的邮件给你，一点链接直接黑掉你的浏览器，把木马植入进去。还用干什么 form post，low 了点。 |
 | 11 fcten 2018-02-06 13:04:22 +08:00 没有严格检查用户输入导致网页被植入恶意脚本是很有可能发生的事情。检查 refer 不能防止这种典型的 csrf 攻击。 |
 | 12 DuckJK 2018-02-06 13:09:00 +08:00 如果 referer 为空放行了请求，在 https 或 iframe 的 base64 是可以请求成功的。 |
 | 13 zarte 2018-02-06 14:07:32 +08:00 都黑进去放东西了还要诱导？ |
 | 14 fucker 2018-02-06 14:11:39 +08:00 我觉得还是加强一下员工安全意识吧。 |
 | 15 tvboxme 2018-02-06 15:12:43 +08:00 这就是漏洞啊，现在多少框架都自带 csrf token 了，长点心吧。。 |
 | 16 BoiledEgg 2018-02-06 15:16:01 +08:00 仅仅验证 refer 本来就不足以防范 csrf 的，csrf token 是必须的 |
 | 17 ushio 2018-02-06 15:44:47 +08:00 不要寄望于公司员工能有多高的安全意识 |
 | 18 Koali 2018-02-06 16:54:35 +08:00 这种漏洞只需要发送请求的时候给个随机数就可以了 |
 | 19 lightening 2018-02-06 17:03:44 +08:00 为什么不用 CSRF token ？+1 |
 | 20 picasso250 2018-02-06 17:31:02 +08:00 我之前在公司做过一次演习,用假域名做了 fish 站,只有一个登录界面. 然后发了一封邮件(用外网邮箱), 结果拿到了 5%用户的密码. |
| 21 FONG2 OP @picasso250 我就是这个想法，我做到浏览器内的防跳转保护足以，至于用户是否有足够的安全意识我保证不了 如果用户随意打开陌生文件，加 token 其实也是防不住的 |
 | 22 husky 2018-02-06 18:20:36 +08:00 想请教下楼主准备怎么处理这个漏洞 |
 | 23 menc 2018-02-06 18:57:19 +08:00  1 算典型的安全漏洞。 现在的安全渗透不像你想象的那种，一条路走到黑。现在的安全渗透流行个黑话叫 APT，讲究一个步步为营长期渗透稳扎稳打，社会工程学，翻垃圾桶，公司楼下蹭 WIFI，和公司人员拉关系，都是安全渗透的一环。很多安全案例本身就是首先黑进一个员工电脑，再进行后续其他操作。 所以是安全漏洞，要防范。 给一个建议，安全水很深，虽然是计算机行业，但是和码农不是一个领域，在他们的领域建议听他们的。 |
 | 24 GG668v26Fd55CP5W 2018-02-06 19:03:53 +08:00 via iPhone 本地首次请求 refer 为空，可以成功 在我司域名服务器 refer 合法，可以成功 首次 referer 为空也能成功？你这不但没 csrf token，对 referer 的检查也怪怪的。什么鬼 |
| 25 FONG2 OP |
 | 26 ytmsdy 2018-02-06 20:19:01 +08:00 via iPhone 算啊！假如在一个内网和外网都通的环境下，在外网的网页上加入自动 post 到内网网站的 form ！ |
 | 29 binux 2018-02-07 00:11:59 +08:00 via Android 1 按照你的说法，反正用户电脑会被黑，那用户密码也不要有了，填个用户名就让登录就行了，反正关键业务有二次鉴权。 |
| 33 FONG2 OP @slgz 如果有资源学得很快的，我一年前还在上学天天打游戏。。。 经历半年和安全公司打交道，看看文档、聊聊天。常见攻击方式、原理都懂了 只是今年换了个安全公司，把本地脚本 post 也算 csrf 一时没适应过来 |
 | 34 AV1 2018-02-07 10:26:41 +08:00 如果检查 referer 的合法性，至少能防范外部网站、本地文件、DataURL 页面的跨站请求伪造。 如果是“另一个场景 黑客攻破我司服务器，放置一个内嵌 post 的 html，地址为：www.我司域名.cn/test.html 用户点击被攻击”，这明显已经不是 CSRF 了，CSRF 本意就是跨站请求伪造（注意“跨站”），而你这个例子已经是你自己站点被黑了。不是你防住了 CSRF 就能避免的。根本办法还是防止你的网站被黑。 |
 | 35 slgz 2018-02-07 10:29:47 +08:00 @FONG2 公司，现在就是让我独立干。但是，写代码的事情也不能落下。现在，完全都是用阿里云的产品，包括服务器、web 防火墙之类的，感觉，完全接触不到，正经人。只能自学，但是，最近代码任务也重，感觉没时间去 |
 | 36 SlipStupig 2018-02-07 10:38:57 +08:00 很多邮件客户端为了支持 HTML 解析，集成了 webkit，比如: foxmail < 7.0,只发一个邮件，都不用你点，只要你收到了就可以可以在本地执行 JS， 你说的本地场景 1，是理论可行， 至于场景 2 完全是多此一举 |
| 37 SlipStupig 2018-02-07 10:41:31 +08:00 场景 1：完全可以通过恶意 JS， 去控制员工机器然后去做跳板，这种 CSRF 已经不属于伪造范畴了，也是正确的废话 |
| 38 FONG2 OP @DOLLOR bingo 文档提供者原话就是这样举例的 我都不知道怎么跟他聊天 一个中低程度漏洞，条件要扯上服务器被黑、用户被黑，搞得我相当反感 |
| 39 FONG2 OP @SlipStupig 是的，我觉得，场景 1 算为 csrf 漏洞有点牵强，要 100%安全，是不是每一个请求都要来一个人机识别校验？但是漏洞确实可以这样被利用，OK，我加了 session token。 场景 2 在讨论的时候我都想爆粗了 |
| 40 FONG2 OP @SlipStupig 我还有一个疑问，场景一是建立在用户已登录且保持登录状态的情况下的，邮件客服端发起的请求能带上默认浏览器的 cookie 吗？ |
 | 41 mitnick 2018-02-07 14:23:36 +08:00 单从技术角度出发这属于标准的 CSRF 攻击，但是至于说危害和影响，另算 |
| 42 binux 2018-02-08 01:41:00 +08:00 你允许 referere 为空，是无法防范「 a 站内嵌 b 站 post，用户登录 b 站并打开 a 站，导致被攻击」的，a 站有很多种方法让 refereer 为空。 |
 | 43 wizardforcel 2018-02-08 09:54:01 +08:00 算文件上传。 只要你的站点有 XSS 或者文件上传漏洞，所有 CSRF Token 全部白费。 文件上传这种低级漏洞现在都很少见了，不要为了防止高级漏洞而忽视了这种低级的。 |
| 44 SlipStupig 2018-02-08 10:53:31 +08:00 @FONG2 既然我能本地执行 js，我肯定会进行权限提升，然后得到你浏览器保存的所有数据，为什么还要绕这么大一个圈呢？ |
 | 45 PHPer233 2018-03-04 22:15:43 +08:00 via iPhone 即使你用 token 验证也不是绝对安全。如果你的网站存在 xss 漏洞，那么黑客可以通过 ajax 获取 token，然后再通过 ajax 自动发送 http 请求。全过程用户毫无感知～我建议所有的敏感操作都要附带 token，从一定程度上防止 csrf 攻击。 |
Select Language