举个例子吧 下面让我们以网上商城的买家在商品评价中上传图片这个功能来讲讲如何实践这“三板斧”。假设我们从项目初期就加入了,那么我们大致有七件事情要做: - 识别系统中有价值的数据;
- 在需求分析阶段加入恶意用户需求;
- 针对恶意用户需求设计测试用例;
- 参与启动恶意需求的开发;
- 在开发环境验收恶意需求的实现;
- 在测试环境中进行安全测试;
- 向团队反馈所发现的安全漏洞。
不要担心,这不是7个全新的事情。这只是在每个需要测试人员出现的地方增加了安全的工作而已。 1. 识别系统中有价值的数据 很多人认为执行测试才是测试,而我们的安全测试从这里就开始了。
了解了业务以后,我们需要考虑系统中会有什么有价值的数据。这是为下一步加入恶意用户需求做准备。对于一个网上商城,有价值的数据可以包括产品信息、订单信息、用户信息、支付,等等。
这个环节对我们测试人员来说并没有太多额外的工作,毕竟我们做非安全测试的时候也是需要了解业务。不过要注意了,我们要测试的“图片上传功能”是一个涉及有价值数据的功能。我们需要提高警惕了。 2. 在需求阶段加入恶意用户需求 恶意用户需求是用来记录恶意用户想要在系统中达到的目的。与普通用户需求的区别是,我们不是要去实现它,而是使用它帮来助我们远离对系统使用者“不恰当的信任”。通常我们需要针对每一个合法用户需求来增加一个或多个相对应的恶意用户需求。
举个例子,如果我们这个“图片上传功能”的合法用户需求为:
作为一个买家,我想在对商品进行评价的时候上传图片作为买家秀,以便于参加返现营销活动。
那么对应的恶意用户需求可以是:
作为一个恶意用户,我想破坏买家秀返现活动,以便破坏商城的营销活动。
“破坏买家秀返现活动”是一个大的目标。为了设计用例方便,它可以被细分为一系列小目标。比如: 有了恶意用户需求的主干信息,我们就可以开始下一步设计安全测试用例了。 3. 针对“恶意用户需求”设计测试用例 现在我们需要做的是努力把自己限制在“恶意用户”的角度做头脑风暴:“到底有什么方法可以使买家无法上传图片信息呢?”, “让页面无法正确显示买家秀图片又怎么做到?”嗯,也许最直接的办法就是让服务器所在的机房断电、断网之类的。这是些不错的想法,虽然执行难度有点大。没关系,记录下来。除此之外,我们还可以有其他测试用例,比如: - 使存储图片的磁盘空间被占满而无法接受新的图片;
- 使处理上传图片的进程繁忙而无法接受新的上传任务;
- 上传特别大的图片使用户的客户端需要很长时间才能下载完
- 上传伪装成图片的恶意代码,进一步获取服务器权限,删除所有的买家秀图片;
- 等等
如果这个时候想到新的测试用例也同样记录下来,比如“我想不购买也上传买家秀图片以获得返现”之类的。
不用太担心这个阶段的测试用例过于“疯狂”或者不够完整,毕竟我们对于系统的实现还不是很了解。我们会在接下来的环节中完善具体的步骤。 4. 参与启动恶意需求的开发(evil story kickoff) 在开发人员开始开发合法用户需求之前,我们需要跟业务分析人员、开发人员一起沟通需求的内容。在敏捷软件开发项目中我们叫它story kickoff,即用户故事启动。当有了对应的恶意用户需求时,我们必然也要把它也加到启动的范围里。目的是把我们头脑风暴出来的测试用例跟所有的角色来沟通。预防胜于检测。 5. 在开发环境验收恶意需求的实现 100%预防软件的缺陷与漏洞是不太可能的,所以这个环节的存在是为了提早反馈。
我曾经经历过一个项目,都快上线了才决定做安全测试,结果测出来的问题之一是用户会话(user session)不能正确过期的问题,经过一番研究,发现需要对系统设计的架构进行比较大的修改,只能做个临时的修复让系统先上线,然后再把系统的架构给改了,重写这部分功能,重新测试。代价非常高。所以不管是安全测试还是非安全测试,”在开发环境验收恶意需求的实现“这个步骤都不能缺少。
而这个环节存在的第二个目的是让我们可以从开发人员那里得到支持-具体实施的细节,帮助我们完善具体的测试用例。比如在这个时间点我们若从开发人员那里得知系统的后台没有对图片上传者做身份验证,我们就可以至少增加一个测试的用例:“恶意用户以其他用户的身份上传一个风马牛不相及的图片”。有时候错误的图片比没有图片更具有杀伤力。 6. 在测试环境中进行安全测试 终于到了运行测试的阶段。可能这个时候我们之前想到的测试用例已经被开发人员给解决。如果是这样那就太好了。但是,事实并非有这么美好。第一,可能这些用例只是在开发环境上成功通过了,但是在理想的测试环境里,也就是类产品环境里,这些用例可能并不能完全通过;第二,肯定还有其他需要探索的地方。这时我们就可以用OWASP Zap、Burp这样的工具来辅助我们把之前的安全测试用例执行一次,同时还再可以对系统的安全性做一下探索测试。 7. 向团队反馈所发现的安全漏洞 都测得差不多的时候,我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是,当我们反馈安全漏洞的时候,要考虑是否不同漏洞结合起来会增加系统的安全风险。举个例子:如果有两个安全漏洞,一个是系统没有很强的用户账户密码规规则,另一个是系统没有对上传图片的大小做限制,那么恶意 用户把这两个漏洞一结合起来,事情就比原来风险大很多。那么我们就必须建议提高这两个漏洞中任意一个的优先级。 当我们用“三板斧”走完这七步以后,我们已经可以把很多安全漏洞都挖出来了。是不是没有想象中的难?所以,测试同仁们,让我们做安全测试吧!
|