甲方眼里的安全测试

纵观互联网上公开的文章，专门介绍甲方安全测试的少之又少。入职甲方安全已将近一年又三个月，从甲方角度来做安全测试的流程和思路、痛处与难点也越加明晰。早就想着能总结一篇见闻与大家分享，诸多原因迟迟未能动笔。忽然，今夜性情大起，遂点亮台灯、打开电脑记录下这些零散的思绪。

一提到安全测试，不得不想起渗透测试。个人认为在测试覆盖面、流程以及想要达到的目标上有所差异吧。在甲乙双方的安全（渗透）测试在工作中，所体现出来的具体形态也各不一样，主要表现在安全测试流程、测试checklist、漏洞生命周期、安全测试风险以及更多更高的要求等方面。

本文以安全建设起步不久，但是有一定基础流程运转的甲方安全团队为例。

1、专属名词说明

在乙方做安全，或许没有听过或听过但不够了解这些名词。

1.1 SDL

SDL（Security Development Lifecycle），一直被安全从业者知悉。尤其是最近几年以来，越来越被甲方应用安全所看重，不少公司也都在筹划、实施或践行着这整套软件安全流程，都希望能落地生根。

安全测试作为SDL中的重要一环，实现准确、高效的自动化也是大家追求的终极目标。目前为止，估计也就大型互联网公司有所建树。至于我们，还在努力的道路上。

1.2安全提测

如果业务方有新的应用需要发布或老应用有新增功能，则需要进行安全提测，测试通过后才能上线发布。安全提测流程便由此产生，由有需求的业务方（一般而言是开发）发起安全任务单，提交至安全部门受理。安全任务单的工作流程为：

安全任务单的主要内容为：

1.3漏洞工单

通俗来讲，也就是提交给漏洞整改责任人（开发或运维）的漏洞工单。其内容必不可少的应该包括：漏洞名称、漏洞等级、整改责任人、所属部门、漏洞描述、漏洞危害、修复建议、提交人。

1.4漏洞整改通知单

当安全测试完毕后，需要向提测的业务部门进行正式的结果反馈，这时一封囊括所有漏洞以及需要完成整改时间的邮件十分有必要。一方面是告知业务方，让领导知晓，安全测试已经完成；另一方面是督促其进行漏洞修复的重要依据。

1.5测试/预发/生产环境

通常情况下，乙方渗透测试工程师从外网做测试，目标均是生产环境（不排除有的厂商会不做防护的把测试环境对外网开放）。但是在甲方，首先接触的便是测试环境，基本上所有的安全测试工作均在该环境。测试环境一般都和生产环境不一样，情况比生产环境复杂而且存在的安全问题比较多；预发环境的配置完全按照生产环境，漏洞修复后的最后验证可能会发生在该环境和生产环境。

2安全测试流程

为了进一步说明甲乙方的安全测试工作差异，该部分将安全测试涉及到的流程进行列举。

乙方渗透测试流程

乙方工程师在获得用户渗透测试授权书后，可能将着手开始测试。

甲方安全测试流程

甲方安全团队在收到业务方安全提测后，将先与提测方进行业务相关沟通（具体环境、功能等）并评估工作量，再进行测试，测试过程中一般都会进行多次沟通，对象包括对应开发、测试、产品甚至运维。

2.1漏洞描述

当发现漏洞进行提交时，需要尽可能详细的写出漏洞细节，比如漏洞发生的位置（是否需要登录、哪个功能下的某处），附上请求包并指明存在漏洞的参数，将会在后续的回归验证工作中，减轻负担提高工效。

2.2漏洞危害

有图有真相，漏洞利用成功的截图应该是放在漏洞描述中。到了阐述漏洞危害，可以适当的偏向更严重后果，因为漏洞危害的定级确定漏洞修复的优先级与速度。难免会有开发过来挑战，所以要做好充分理解漏洞及利用场景、演示漏洞进行攻击的准备。

2.3修复建议

在甲方会发现，编写漏洞修复建议时不能仅仅是依靠百度。在充分理解业务场景的基础上，提出针对性的建议。比如一个富文本编辑框存在XSS漏洞，如果单纯的提出对输入和输出做html实体编码或转义特殊字符，显然不能让开发信服。

更重要的是，常见的web漏洞单一的让开发去各自修复，显然不是一件明智的事情。如果安全团队有能力开发或请中间件等团队开发出安全组件，在软件开发过程中或遇到漏洞时进行调用，将不会占用开发过多的时间和精力，让他们花更多的心思在开发上，才是最佳之道。对于不通用的漏洞，安全团队的技能沉淀工作需要建立起来，下次在遇到相同漏洞时做到有所积累有所参考。

3、测试checklist

3.1测试思路

不少甲方会有自己的安全测试checklist，在测试过程中严格按照表中具体的每一项测试（独具特色的、方便以后类似项目测试）进行流程化的测试操作。

在乙方，当工程师找到拿得出手的漏洞并不想在项目上投入更多精力时；在甲方，工程师可能会说功能点还没走完，还得继续测试。这就是双方的真实写照，甲方要求的是覆盖面，而乙方更多的是看重结果。

3.2不同之处

在测试方面，技能点都是通用的。但着重点在不同的公司会有所不同，比如：

不起眼的漏洞被列为高危：

协议安全，“一朝被蛇咬十年怕井绳”。

对外应用系统强制使用https，已逐渐成为规矩。去年公司某业务系统被某地运营商劫持插入小广告，导致业务功能受影响，客户投诉。至此，若发现对外应用系统不上https将会被提高危漏洞一枚，这也是最简单的高危漏洞。不安全的协议还有很多，ftp-升级->sftp，telnet-换为->ssh等。

不曾测过的漏洞被列入必测项：

日志安全，对于乙方的工程师肯定不会测试这个漏洞（查看后台中间件打印的日志是否存在敏感信息）。因为没有权限，所以在乙方的安全测试手册中一般也不会出现。但是在甲方，测试环境的日志是可以被很多人（包括开发与测试以及其他能访问到服务器且有权限的人）查看。开发常常为了调试方便，打印各类信息在日志中，严重的有支付密码、交易账号密码，有的虽然做了加密处理，但风险仍旧存在。

不以为然的问题却被当做漏洞：

中间件版本信息泄露，最常见的便是tomcat版本信息泄露。从利用场景、难度、危害来看，无疑是最鸡肋的。倘若公司的所有服务器全都有这个问题，就难以不得不管。在批量修复的同时，还需要通知运维修改虚拟机模板，从源头解决问题。

4、漏洞生命周期

漏洞生命周期即从发现漏洞到修复漏洞，形成一个闭环。其中，推动漏洞整改、漏洞回归验证、在同样的环境中发现相同漏洞并整改，是甲方安全测试过程中不可或缺的部分，漏洞整改率也常被纳入安全部门的考核指标。最简单的常规流程为：

而在实际推动过程中，常常会遇到漏洞整改责任人的“推诿”：

这为什么是漏洞，应不应该改？

这是前端的问题还是后端的问题，是不是要给别人改？

这是历史遗留的问题，别人交接给我的，这个能不能以后再修复？……

拥有技术与语言沟通能力已成为安全人员具备的能力，要使开发修复漏洞较好的方法是从技术上说服他们，取得他们的信任，以后再到漏洞修复问题将会变得容易很多。

4.1红线管理

对于推动漏洞整改，单从技术和沟通仍显得势单力薄。先制定出安全质量红线规范，用来强制性的要求或进行约束，是十分有必要的。其内容可以包括如下规定：

4.2推动整改

与漏洞整改责任人面对面的协同修复漏洞，算是较快捷的一种方法。在配合的过程中，增进了双方安全需求的了解，有助于提升效率。有效的避免修复之后，回归验证依旧存在或发现可以绕过等窘境。除此之外，安全人员还可以从开发、运维那里收获到不同场景的漏洞具体修复方法。当然了，并不是所有漏洞都需要亲力亲为的去参与，一份规范的漏洞修复指导书能起上作用。故，在平时的漏洞整改过程中，应该有意识的去收集公司漏洞修复方案，做到标准化、规范化的累积。

4.3走单不走心

这是最令人痛心疾首的事情了，好不容易安排出时间回归验证漏洞，没想到做了很久的准备工作（例如回归app的漏洞，需要与测试或开发沟通获得一个最新的app，然后安装设代理，如果https且换了手机还需要导入证书，其次可能需要测试账号…），真正需要回归验证时却发现漏洞依旧存在。这期间的问题很多，诸如：开发以为自己修复好了，实际没有；开发未更新修复好的版本系统……以下截图便是后者描述的情况。

为了避免上述事件的发生，在回归验证前最好找到漏洞整改责任人询问修复情况以及方法。

5、安全测试风险

在甲方，安全测试的每个环境都可能存在风险，暴力破解、常规web漏洞扫描，也能导致安全部门背故障分。

5.1暴力破解事故

暴力破解是验证业务系统账户体系设计好坏以及系统防护程度的有效方法，但并不是在什么情况下都适合，稍有不慎就会酿成大错。

安全测试人员在测试环境中，对某内部系统弱口令漏洞进行回归验证。使用burp工具设置工号范围（只影响公司内部人员），加载弱口令进行爆破验证。由于账号乱用与业务逻辑缺陷，导致业务方领导收到验证短信，并将此次事件定级为安全事件。

5.2漏洞扫描风波

常规漏洞扫描是安全部门的常态化事务之一，但往往在意想不到的地方会出现问题。

令人胆战心惊的业务设计：系统的菜单控制存在未授权访问漏洞，导致任意人员均可对菜单进行增删改查操作。

某业务系统存在高危漏洞，导致扫描器在进行常规扫描时，插入多条测试记录，同时删除6条与菜单权限相关的数据，引起系统异常。从而，造成安全事件。

6、更多更高要求

以上部分大多都是通过手工完成，虽然会掺杂一些半自动化的操作（比如：burpsuit+sqlmap，流量自动检测sql注入等），但安全测试仍旧会成为瓶颈。如果是大一点的甲方公司，业务系统繁多，每周上线发布的次数也不少，更是不能满足安全测试需求。因此，自动化安全测试便成为迫切的需求。

在做自动化的过程中，难免会遇到漏洞检测率、准确率等难题。若是细致到场景，可能将出现请求包中token一次失效，加载payload后重放测试无效等困境。总之，自动化安全测试之路，任重而道远。