第一，转换视角
以一个用户登录功能为例，当输入错误的用户名登陆时，提示信息为“该用户名不存在”；当用户名正确而密码错误时，提示信息变成“密码输入错误。”对于真实的用户来说非常好，能有效缩小纠错的范围。但是安全测试人员会跳出来：“这个提示信息需要改！敏感信息暴露了！”因为提示信息，恶意的系统使用者可以推测出哪些用户名已经存在于系统中，然后利用这些用户名可以再进行密码的暴力破解，缩小破解的范围。所以，这个信息虽然为合法用户提供了便利，也为不怀好意的系统使用者提供了便利。而往往这种便利为恶意的系统使用者带来的好处远大于给合法用户带来的好处。
第二、改变测试中模拟的对象
为了能以不同的视角来观察软件，我们必须改变我们所模拟的对象。这也是一个让我们刻意练习转换视角的有效方法。
我们在做非安全测试的时候通常把自己想象成一个合法用户，然后开始验证系统是否能完成预设的目标。比如对于一个网上商城，我们会验证系统是否能让用户完成商品的浏览与购买，我们也会测试一些异常的行为，比如购买的商品数量不是数字而是一串无意义的字母时，目的是看系统是否能比较优雅的做出回应。我们这么测试的目的往往是为了确保用户误操作以后还能够继续他们的购买，或者说不要给系统造成什么严重的伤害。
如果要做安全测试，我们则必须去模拟系统的另一类使用者－恶意用户。他们的目的是为了寻找系统中可钻的漏洞。比如同样是一个网上商城，恶意用户的目标之一就是要想办法以较少的钱，甚至不付钱就能拿到商品。所以，如果恶意用户进行了“误操作”，他们不会停留在“误操作”，而是通过“误操作”来看系统是否给自己提供更多的线索。
所以，我们转换我们测试时所模拟的对象，把思维从一个合法用户的视角中拉出来，转换成一个恶意用户。这需要一点时间来刻意练习。
第三、使用专用的测试工具
有了思维的转换，我们可以加入新的测试想法。但是，在具体做安全测试的时候我们会发现并不是那么容易去模拟恶意用户的行为。毕竟系统的前端会给我们很多的屏障。而且恶意用户可不总都是从系统前门进去的。这时候，使用一些工具，比如OWASP Zap(https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)、Burp(https://portswigger.net/burp/)等是非常有帮助的。我们可以在系统界面上执行功能测试的用例，用这些工具来获取http请求，篡改后发送给后台服务器。有了这些实用又比较容易上手的工具，我们就可以执行很多恶意用户的操作场景了。
能做到这三点，起步就基本够用了。
举个例子吧
下面让我们以网上商城的买家在商品评价中上传图片这个功能来讲讲如何实践这“三板斧”。假设我们从项目初期就加入了，那么我们大致有七件事情要做：
识别系统中有价值的数据；
在需求分析阶段加入恶意用户需求；
针对恶意用户需求设计测试用例；
参与启动恶意需求的开发；
在开发环境验收恶意需求的实现；
在测试环境中进行安全测试；
向团队反馈所发现的安全漏洞。
不要担心，这不是7个全新的事情。这只是在每个需要测试人员出现的地方增加了安全的工作而已。
1. 识别系统中有价值的数据
很多人认为执行测试才是测试，而我们的安全测试从这里就开始了。
了解了业务以后，我们需要考虑系统中会有什么有价值的数据。这是为下一步加入恶意用户需求做准备。对于一个网上商城，有价值的数据可以包括产品信息、订单信息、用户信息、支付，等等。
这个环节对我们测试人员来说并没有太多额外的工作，毕竟我们做非安全测试的时候也是需要了解业务。不过要注意了，我们要测试的“图片上传功能”是一个涉及有价值数据的功能。我们需要提高警惕了。
2. 在需求阶段加入恶意用户需求
恶意用户需求是用来记录恶意用户想要在系统中达到的目的。与普通用户需求的区别是，我们不是要去实现它，而是使用它帮来助我们远离对系统使用者“不恰当的信任”。通常我们需要针对每一个合法用户需求来增加一个或多个相对应的恶意用户需求。
举个例子，如果我们这个“图片上传功能”的合法用户需求为：
作为一个买家，我想在对商品进行评价的时候上传图片作为买家秀，以便于参加返现营销活动。
那么对应的恶意用户需求可以是：
作为一个恶意用户，我想破坏买家秀返现活动，以便破坏商城的营销活动。
“破坏买家秀返现活动”是一个大的目标。为了设计用例方便，它可以被细分为一系列小目标。比如：
-让用户无法上传图片
-让页面无法正确显示图片等等
有了恶意用户需求的主干信息，我们就可以开始下一步设计安全测试用例了。
3. 针对“恶意用户需求”设计测试用例
现在我们需要做的是努力把自己限制在“恶意用户”的角度做头脑风暴：“到底有什么方法可以使买家无法上传图片信息呢？”， “让页面无法正确显示买家秀图片又怎么做到？”嗯，也许最直接的办法就是让服务器所在的机房断电、断网之类的。这是些不错的想法，虽然执行难度有点大。没关系，记录下来。除此之外，我们还可以有其他测试用例，比如：
-使存储图片的磁盘空间被占满而无法接受新的图片；
-使处理上传图片的进程繁忙而无法接受新的上传任务；
-上传特别大的图片使用户的客户端需要很长时间才能下载完
-上传伪装成图片的恶意代码，进一步获取服务器权限，删除所有的买家秀图片等等
如果这个时候想到新的测试用例也同样记录下来，比如“我想不购买也上传买家秀图片以获得返现”之类的。
不用太担心这个阶段的测试用例过于“疯狂”或者不够完整，毕竟我们对于系统的实现还不是很了解。我们会在接下来的环节中完善具体的步骤。
4. 参与启动恶意需求的开发（evil story kickoff）
在开发人员开始开发合法用户需求之前，我们需要跟业务分析人员、开发人员一起沟通需求的内容。在敏捷软件开发项目中我们叫它story kickoff，即用户故事启动。当有了对应的恶意用户需求时，我们必然也要把它也加到启动的范围里。目的是把我们头脑风暴出来的测试用例跟所有的角色来沟通。预防胜于检测。
5. 在开发环境验收恶意需求的实现
100%预防软件的缺陷与漏洞是不太可能的，所以这个环节的存在是为了提早反馈。
我曾经经历过一个项目，都快上线了才决定做安全测试，结果测出来的问题之一是用户会话（user session）不能正确过期的问题，经过一番研究，发现需要对系统设计的架构进行比较大的修改，只能做个临时的修复让系统先上线，然后再把系统的架构给改了，重写这部分功能，重新测试。代价非常高。所以不管是安全测试还是非安全测试，”在开发环境验收恶意需求的实现“这个步骤都不能缺少。
而这个环节存在的第二个目的是让我们可以从开发人员那里得到支持－具体实施的细节，帮助我们完善具体的测试用例。比如在这个时间点我们若从开发人员那里得知系统的后台没有对图片上传者做身份验证，我们就可以至少增加一个测试的用例：“恶意用户以其他用户的身份上传一个风马牛不相及的图片”。有时候错误的图片比没有图片更具有杀伤力。
6. 在测试环境中进行安全测试
终于到了运行测试的阶段。可能这个时候我们之前想到的测试用例已经被开发人员给解决。如果是这样那就太好了。但是，事实并非有这么美好。第一，可能这些用例只是在开发环境上成功通过了，但是在理想的测试环境里，也就是类产品环境里，这些用例可能并不能完全通过；第二，肯定还有其他需要探索的地方。这时我们就可以用OWASP Zap、Burp这样的工具来辅助我们把之前的安全测试用例执行一次，同时还可以对系统的安全性做一下探索测试。
7. 向团队反馈所发现的安全漏洞
都测得差不多的时候，我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是，当我们反馈安全漏洞的时候，要考虑是否不同漏洞结合起来会增加系统的安全风险。举个例子：如果有两个安全漏洞，一个是系统没有很强的用户账户密码规则，另一个是系统没有对上传图片的大小做限制，那么恶意用户把这两个漏洞一结合起来，事情就比原来风险大很多。那么我们就必须建议提高这两个漏洞中任意一个的优先级。
原文地址：
http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-test?utm_source=articles_about_Security&utm_medium=link&utm_campaign=Security