如果要做安全测试，我们则必须去模拟系统的另一类使用者－恶意用户。他们的目的是寻找系统中可钻的漏洞。比如同样是一个网上商城，恶意用户的目标之一就是要想办法以较少的钱，甚至不付钱就能拿到商品。所以，如果恶意用户进行了“误操作”，他们不会停留在“误操作”，而是通过“误操作”来看系统是否给自己提供更多的线索。

　　所以，我们需要转换测试时所模拟的对象，把思维从一个合法用户的视角中拉出来，转换成一个恶意用户。这需要一点时间，就如同之前看到的画，如果我们一开始看到的是人脸，要想下一次第一眼看到的是花瓶，我们需要时间来刻意练习。

　　第三，使用专用的测试工具

　　有了思维的转换，我们可以加入新的测试想法。但是，在具体做安全测试的时候我们会发现并不是那么容易去模拟恶意用户的行为。毕竟系统的前端会给我们设置很多的屏障。而且恶意用户可不总是从系统前门进去的。这时候，使用一些工具，比如OWASP Zap()、Burp()等是非常有帮助的。我们可以在系统界面上执行功能测试的用例，用这些工具来获取http请求，篡改后发送给后台服务器。有了这些实用又比较容易上手的工具，我们就可以执行很多恶意用户的操作场景了。

　　能做到这三点，起步就基本够用了。

　　举个栗子吧??

　　下面让我们以网上商城的买家在商品评价中上传图片这个功能来讲讲如何实践这“三板斧”。假设我们从项目初期就加入了，那么我们大致有七件事情要做：

识别系统中有价值的数据；

在需求分析阶段加入恶意用户需求；

针对恶意用户需求设计测试用例；

参与启动恶意需求的开发；

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

在测试环境中进行安全测试；

向团队反馈所发现的安全漏洞。

　　不要担心，这不是7个全新的事情。只是在每个需要测试人员出现的地方增加了安全的工作而已。

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

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

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

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

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

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

　　举个例子，如果我们这个“图片上传功能”的合法用户需求为：作为一个买家，我想在对商品进行评价的时候上传图片作为买家秀，以便于参加返现营销活动。那么对应的恶意用户需求可以是：为一个恶意用户，我想破坏买家秀返现活动，以便破坏商城的营销活动。“破坏买家秀返现活动”是一个大的目标。为了设计用例方便，它可以被细分为一系列小目标。比如让用户无法上传图片、让页面无法正确显示图片等等。

　　有了恶意用户需求的主干信息，我们就可以开始下一步设计安全测试用例了。

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

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

使存储图片的磁盘空间被占满而无法接受新的图片；

使处理上传图片的进程繁忙而无法接受新的上传任务；

上传特别大的图片使用户的客户端需要很长时间才能下载完

上传伪装成图片的恶意代码，进一步获取服务器权限，删除所有的买家秀图片；

等等

　　如果这个时候想到新的测试用例也同样记录下来，比如“我想不购买也上传买家秀图片以获得返现”之类的。