安全摘记 | 互联网安全小兵的日常

*本文原创作者：starshine，本文属FreeBuf原创奖励计划，未经许可禁止转载

生活不只有眼前的苟且，还有诗和甲方。于是，我来到了甲方，成为了一个互联网安全小兵。

在乙方Web安全研究团队的时候，可能更关注于某一方向的安全技术，像一个侠客的角色。

而到了互联网公司，也算甲方了，那么我们安全工程师不光要关注安全技术本身，更重要的是要理解安全和业务的关系，这时候我们要有一个建设者的意识，要思考如何帮助我们的产品更健壮，让我们的业务更健康。

当然，不积跬步无以至千里，作为一个互联网安全小兵，还没上升到安全策略和方案的层次，我的日常还是与一个个漏洞为伴，就分“应急响应中心（SRC）”和“产品安全内测”两部分工作来说几点体会吧~

一、应急响应中心 （SRC）

我们不生产漏洞，但我们不只是漏洞的搬运工。

在SRC的日常工作流程简要描述：

接收漏洞–>验证漏洞–>通知相关负责人修复（可能会反复讨论漏洞危害和修复方法）–>漏洞复测–>漏洞确认修复

那么，从一个漏洞被发现，到最终修复这就是一个闭环，顺利的话是这样，不顺利的话其中的曲折和槽点就…

1、有一种懂叫白帽子以为你懂

以前，自己去漏洞平台交洞的时候，因为懒或者确实不晓得，在“危害”和“修复建议”里往往就跟风填个“你懂的”(类似的还有”你们更专业”，”你们更了解”，”大家都懂的”)，装作老司机的样子（哥就是这么潇洒）~

直到我来到了SRC…我想哭诉，我不懂啊，表哥求带啊，表哥你交了漏洞你要对我负责啊！！！

举个栗子，看图

亲爱的，你告诉我，你贴张图，一句“你懂的”，是想说啥 ？？？

我真是一脸懵逼.jpg~你好歹给个问题链接啊，你好歹告诉我下你这个“dz_ssrfscan.py”程序能分享不，能下载来测试不…此时的我，只能45°仰望天空，仿佛沙子迷了眼睛。

不哭，这个时候，我不能辜负白帽子的信任，不能为咱SRC丢脸！通过分析标题，找到对应的站点，然后看截图工里的“dz_ssrf”推测是discuz的ssrf漏洞（搞得跟侦探推理样），如果是自己之前没处理过的，就要从网上找相应的文章，然后看着文章学习测试，好不容易哦测出来了，半天都过去了…

所以，我要在这里忏悔，我以后再也不“你懂的”了，所以，SRC的小兵们最喜欢的就是那种漏洞报告写的清晰明确，复现所需的信息都提供，还提供自己的修复建议的，我们一般管这种白帽子叫，亲哥！嗯，亲哥！有加分哦

嗯，漏洞确认环节我这已经完成了，下一步就是通知业务部门的负责人。

2、一脸懵逼：XSS就是弹个框？这个漏洞我打开URL一片空白是不是就没问题？

上文中处理的这个Discuz的ssrf漏洞是没有回显的，所以，我已经意识到接下来的蛋疼了。写好漏洞处理报告，发给业务负责人。然后就有了下边的对话：

业务：哦我第一次遇到这个漏洞，你这个漏洞能导致啥？ 我：巴拉巴拉….5分钟 业务：好的，我看下…过了5分钟…要不我给你打电话吧 我：好的，然后电话……又过了5分钟 业务：哦好的，那怎么测试呢？ 我：这个漏洞确实比较蛋疼， 你可以对比下我给的两个测试链接 业务：哦，那我打开url页面一片空白，是不是表示就没啥问题？ 我：…..

此处沟通交流省略…最后终于和业务方对漏洞的认识和可能导致的风险取得了共识，我心没碎(^o^)/~

对这个举的ssrf的例子简单说明下，对于没有回显的ssrf，确认的话零成本我是采用通过漏洞接口请求存在和不存在的内网资源然后对比返回时间，通过不存在的文件页面返回时间明显快于存在的文件来推测目标服务器请求了我们提交的url。这个，对于第一次遇到这个漏洞的人来说，确实需要理解。

到了这里，一个漏洞中最难的部分已经完成了。

对于一个已确认的漏洞来说，处理流程中我认为最难的点就是如何帮助业务方也能对漏洞的情况进行复现，并且要动之以情晓之以理将问题解释清楚，让业务方也能理解到漏洞的危害，帮助找到问题的成因。

如果不能良好的沟通，就容易引起误解，比如如果对XSS解释不好的话，业务可能认为XSS就是弹个框…汗

3、修复：方法有多种，落地有曲折

首先，就是工作排期的问题，如果漏洞修复没有和业务方kpi挂钩的话，说服业务方尽快修复还是要多费些口舌的。但是只要大家是为了让业务更好，更安全的话，问题也不大。

然后就是对修复结果的确认。

如果一个反射型的XSS漏洞，然后业务说修复了，最后复查发现，修复的方法就是那个接口禁止了GET方式的HTTP方法，然后一个GET的XSS就变身成了POST方式的XSS…你在逗我吗， b(￣▽￣)d

通过和业务沟通说是因为那个接口被调用较多，不能一下子修改，然后经过讨论，建议将接口的数据声明从html格式声明成json格式，让浏览器不解析执行。

考虑到接口调用较多，难以短时间改变，我们作为安全工程师也理解业务的情况，会定期跟进，直到该漏洞修复，不过对于GET改POST的XSS这种修复方法，作为安全测试者我们是不认可的。

因为，安全工程师就是企业的安全防线，我们理解业务的情况，但是也要有自己对于安全的专业精神和职业操守，对于业务处理进程可以灵活变通，但是对于漏洞处理的方式方法，要认真求证，并坚持自己的专业认知，这就是我们的职业尊严。

强调一点：作为SRC的漏洞处理者，只发现漏洞和能复现漏洞是不够的，更重要的是找到漏洞的成因，并能结合业务情况，给出最合理的修复方案，后边两点是很考察漏洞处理者的水平的。

还有，一个漏洞从被发现到被修复的整个生命周期中，沟通和交流的占比是很高的，应该会超过50%吧，所以，一个合格的SRCer，应该能知其然并知其所以然，同时还要能良好的表达和沟通。

成长在于积累，把漏洞当做朋友，了解它、分析它，通过一个个漏洞的积累与思考，去感知产品与业务的安全症结所在，去探究良方。

所以，身在SRC，服务于白帽子与公司产品和业务团队，我们虽然不生产漏洞，但我们也不只是漏洞的搬运工。

二、产品安全内测

多一些真诚，少一些套路。

公司产品或业务上线前，往往需要安全部门内测，目的是消除一些安全隐患以及对关键功能进行安全性检查，所以内部安全测试也是日常工作重点。这里，也要谈几点感受。

1、自己家的东西就能随意测试吗？

不是这样的，即使是公司内部的产品，也不是说想测就测的。首先，有一个红线，就是对于上线的业务以及业务部署所在的生产服务器，不授权是不应该轻易去测试的，即使是测试，也要尽量不用大流量的扫描或者暴力破解。

因为，对于线上的系统，正常情况下，我们首先要保证的是系统的可用性。想象一下如果电商服务器因为你的测试异常导致宕机5分钟（损失就不说了），这就造成了安全事故。

所以，对于互联网的安全建设者来说，不光要考虑技术，还有纪律！

而大多数情况下是内网的测试环境，这种情况下就不用有太多担心，尽可能去发现更多的漏洞吧~

2、大胆判断，小心求证，降低误报

比如测试目标服务器支持的“不安全的HTTP方法”，当使用OPTIONS方法看到返回包允许PUT、DELETE方法时不要直接判断漏洞存在，要逐个方法进行测试，我们要仔细思考。

首先不同目录中激活的方法可能各不相同，有时候OPTIONS探测出来开放的方法实际上它们并不能使用，还有即使OPTIONS请求返回的响应中没有列出某个方法，但该方法有可能仍然可用。

真正确定后，还要和业务方沟通，是否真的需要开放扩展的HTTP方法，如果确实需要，如何进行权限设定等。

再比如，如果你测试一个登陆口，可以无限制暴力破解，也不能直接就下定论，首先，你要判断登陆口的防暴破策略，包括对访客的识别粒度、账号有效性（是否是注册的账号）、同一账号限制次数、固定密码枚举用户名限制次数乃至账号锁定时间和周期等。

即使这些都确定了，你还要用内外网分别测试对比下，如果测试环境外网可访问，那就要挂代理出去，看是否因为办公网的IP被加入的白名单才导致可暴力破解。

所以，对于漏洞，初步判断后，小心求证，保持和业务方的沟通和联系，及时反馈。

3、不发忽悠式漏洞

所谓“忽悠式漏洞”就是一味强调漏洞利用成功后的危害，一看标题比较严重，仔细看内容发现漏洞利用难度很大，利用成本高，在业务的实际应用场景中可能危害并不大。

我们判断一个漏洞的危害，一个误区就是“以漏洞利用成功后的最大破坏力去判断”，比如通过一个漏洞，我绕过了一个支付APP的锁屏密码。看效果，起码算个中危了，可是仔细分析发现，利用成功需要一些前提条件，比如要能拿到目标的手机来操作，绕过锁屏的时候还要命令环境等…..

那么和实际业务一结合，发现该漏洞利用门槛高，有附带条件，那么整体评估风险可能就会有所降低，根据业务方情况，那么在任务排期紧张的情况下，该漏洞可以推迟修复。

再举个例子，如果一个社交业务的APP，里边有个板块“公共话题讨论区”，谁都可以发表话题，所有用户都可以看到，那么可能会产生什么隐患？

这个时候，我们首先应该测试的就是发表话题的频率，如果发现发表话题的数据包可以快速无限制地重放，那么这就可以被利用来持续产生大量垃圾话题信息。

那“发表频率没有做限制”导致大量垃圾信息这个问题算漏洞吗？

单独看可能不好说，还要结合业务场景来说，如果这些垃圾信息只能用户自己看到，那么危害就很小。

可如果产品的设计逻辑是“用户发送的最新话题以自上而下滚动的方式在公共话题讨论区更新” 且 “应用未对发表的内容进行垃圾信息过滤”的话……

几个逻辑缺陷一结合，这个虽然测试起来没什么技术含量的“漏洞”，一旦被攻击者恶意利用，将导致攻击者用持续的垃圾信息对公共话题讨论区进行持续地刷屏、霸屏，直接影响到了业务的正常秩序以及产品的形象。

这就应该算一个高危甚至严重的漏洞。

参考下微软提出的DREAD风险分析模型，将漏洞和业务相结合，放在大量用户的使用场景中去多角度考虑，来给漏洞可能的风险进行一个综合的评判，这样对业务部门的参考性更实际。

因此，我们在和产品业务方沟通的时候，也应该多一些真诚，少一些套路，建立信任，合作共赢。

《白帽子》那本书里说过，当一个产品其他方面都还可以的时候，那么“安全”也应该成为产品的一个重要属性，那么，我们也应该和业务方传达这个思想，让他们能理解安全部门不是在给他们找麻烦，而是想和他们一起合作将咱们的产品做得更好，更稳健。

而作为互联网公司安全工作者，我们不能光要求小伙伴怎样做，我们自己也应该去践行“安全是产品的一个重要属性”这一理念。

我们要给自己重新定位，当我们在和产品部门沟通解决漏洞问题的时候，我们就是产品部门的一份子，一起想把产品做得更好，这时候，我们就是产品部门的SecPartner（安全合伙人）。

当然，希望当产品部门发奖金的时候，别忘了我们SecPartner哦~

最后的最后，关于互联网公司安全建设，还是比较认同唯品会安全大会上分享的那首诗。

方法都知道，落地很艰难。 领导不支持，一切都免谈。 除了靠自己，还得靠伙伴。

讲真，打铁还得自身硬，安全部门要想工作推动更顺利，用实力和疗效赢得认可才是王道！

*本文原创作者：starshine，本文属FreeBuf原创奖励计划，未经许可禁止转载