认识达内从这里开始

安全测试随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，安全测试实践需要做到哪些事情。

1.识别系统中有价值的数据

很多人认为执行测试才是测试，而我们的安全测试从这里就开始了。

了解了业务以后，我们需要考虑系统中会有什么有价值的数据。这是为下一步加入恶意用户需求做准备。对于一个网上商城，有价值的数据可以包括产品信息、订单信息、用户信息、支付，等等。

这个环节对我们测试人员来说并没有太多额外的工作，毕竟我们做非安全测试的时候也是需要了解业务。不过要注意了，我们要测试的“图片上传功能”是一个涉及有价值数据的功能。我们需要提高警惕了。

2.在需求阶段加入恶意用户需求

恶意用户需求是用来记录恶意用户想要在系统中达到的目的。与普通用户需求的区别是，我们不是要去实现它，而是使用它帮来助我们远离对系统使用者“不恰当的信任”。通常我们需要针对每一个合法用户需求来增加一个或多个相对应的恶意用户需求。

3.针对“恶意用户需求”设计测试用例

现在我们需要做的是努力把自己限制在“恶意用户”的角度做头脑风暴：“到底有什么方法可以使买家无法上传图片信息呢?”，“让页面无法正确显示买家秀图片又怎么做到?”嗯，也许直接的办法就是让服务器所在的机房断电、断网之类的。这是些不错的想法，虽然执行难度有点大。没关系，记录下来。

4.参与启动恶意需求的开发

在开发人员开始开发合法用户需求之前，我们需要跟业务分析人员、开发人员一起沟通需求的内容。在敏捷软件开发项目中我们叫它storykickoff，即用户故事启动。当有了对应的恶意用户需求时，我们必然也要把它也加到启动的范围里。目的是把我们头脑风暴出来的测试用例跟所有的角色来沟通。预防胜于检测。

5.在开发环境验收恶意需求的实现

我曾经经历过一个项目，都快上线了才决定做安全测试，结果测出来的问题之一是用户会话(usersession)不能正确过期的问题，经过一番研究，发现需要对系统设计的架构进行比较大的修改，只能做个临时的修复让系统先上线，然后再把系统的架构给改了，重写这部分功能，重新测试。代价非常高。所以不管是安全测试还是非安全测试，”在开发环境验收恶意需求的实现“这个步骤都不能缺少。

而这个环节存在的二个目的是让我们可以从开发人员那里得到支持-具体实施的细节，帮助我们完善具体的测试用例。比如在这个时间点我们若从开发人员那里得知系统的后台没有对图片上传者做身份验证，我们就可以至少增加一个测试的用例：“恶意用户以其他用户的身份上传一个风马牛不相及的图片”。有时候错误的图片比没有图片更具有杀伤力。

6.在测试环境中进行安全测试

终于到了运行测试的阶段。可能这个时候我们之前想到的测试用例已经被开发人员给解决。如果是这样那就太好了。但是，事实并非有这么美好。一，可能这些用例只是在开发环境上成功通过了，但是在理想的测试环境里，也就是类产品环境里，这些用例可能并不能完全通过;二，肯定还有其他需要探索的地方。这时我们就可以用OWASPZap、Burp这样的工具来辅助我们把之前的安全测试用例执行一次，同时还再可以对系统的安全性做一下探索测试。

7.向团队反馈所发现的安全

都测得差不多的时候，我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是，当我们反馈安全漏洞的时候，要考虑是否不同漏洞结合起来会增加系统的安全风险。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。