今天，很多的软件并没有经过专门的安全测试就被放到互联网上，它们携带着各类安全漏洞暴露在公众面前，其中一些漏洞甚至直指软件所承载的核心敏感信息或业务逻辑。这些漏洞一旦被不怀好意者利用，很可能会给企业造成经济损失。带来负面声誉影响的同时，还可能被起诉、遭到罚款等等，细思极恐。
其中的一部分原因是企业本身安全意识不强，但是很多时候虽然软件企业已经开始意识到这些问题，却苦于缺少专业的安全测试人员，他们不得不冒着极大的风险先上线赌一把运气再说。
既然如此，作为质量代言人的我们，怎能对此置之不理呢？
你也许会问，怎么理？安全测试水太深了。
1
安全测试并不遥远
是的，安全测试在软件测试里面是一个很特别的科目（或作“工种”），很多人都觉得这个科目应该全权交给神秘的安全测试人员来管。这个观念导致很多测试人员徘徊在安全测试的门口却迟迟不进去，包括我自己。
（图片来自：http://www.darkshapes.com/）
直到后来，我非常有幸能够在不同规模的软件开发项目上跟“神秘的安全测试人员”学习如何进行安全测试，发现“神秘的安全测试人员”不光是名字跟我们一样都有“测试”二字，所做的事情在本质上也跟我们测试人员有很多相通之处。
想想看我们都做过什么：
我们修改过url的参数，对不对？他们也是！
我们在数据输入处提供过不合法的数据，对不对？他们也是！
我们尝试过修改只读数据，对不对？他们也是！
我们也测过用户会话是否如期timeout，对不对？他们也是！
Ok，这还不是全部。他们也做测试计划、测试用例设计、bug分析与管理等等。所以，安全测试离我们并没有那么遥远。
当然，我必须承认，安全测试是非常复杂的。一个专业的安全测试专家在某种程度上来说是一个全栈工程师。所以，想要在安全测试上一夜成才不太容易。不过好消息是，作为测试人员的我们却有得天独厚的优势，使我们能够在安全测试上快速起步，帮助团队尽快展开预防并检测安全漏洞的工作。
在这里我想要跟大家分享一下在敏捷开发团队中如何利用我们的测试经验开展安全测试。
2
安全测试并不陌生
首先，让我们先来了解什么是安全测试，我们作为测试人员有什么可以直接用上的技能和经验。
简单来说，安全测试其实就是一个发现软件安全漏洞的过程，旨在保护软件系统的数据与功能。它跟常规测试相似的地方至少有以下几点：
| Summary | Details |
|---|---|
| 目标类似 | 预防、检测系统的缺陷（尽早、频繁反馈系统质量信息） |
| 在软件生命周期中的工作过程类似（以敏捷团队为例） | 1、了解系统业务需求 2、针对业务与系统功能设计用例 3、与其他角色一起启动需求的开发 4、与其他角色一起在开发环境验收需求 5、在测试环境进行全面测试 6、分析并总结测试结果 7、反馈测试结果 |
| 测试用例有很多重合 | 面向用户的测试场景非常类似 |
| 都需要有探索的过程 | 对会对不同的业务场景有目的的进行探索 |
| 都要有测试人员必备的“怀疑态度” | 对开发人员的代码保持友好而警惕的态度 |
1. 目标类似
不管是常规测试还是安全测试，都有一个原则：预防胜于检测。这个比较容易理解，不管是常规测试的缺陷也好，还是安全测试的漏洞也好，如果能预防使它不发生，就省了后期的修复与验证工作。如果不能成功的预防缺陷，能早一些发现的话，肯定比晚发现的修复的成本低。
2. 在软件生命周期中的过程类似
以敏捷开发团队为例，常规测试人员在各个阶段做的事情，安全测试人员也要做：
了解业务的需求，以避免混乱的测试优先级；
针对业务与系统功能设计用例：常规测试需要关注系统功能，安全测试同样也不能脱离系统功能；
与其他角色一起启动需求的开发：沟通测试用例，避免因为沟通不足造成返工；
与其他角色一起在开发环境验收需求：尽早提供反馈，发现缺陷时开发可以马上修正；
在测试环境进行全面测试：针对端到端的场景进行测试，尽可能把第三方系统（如果有的话）也包括进来；
分析并总结测试结果：整理问题清单，排列优先级；
反馈测试结果：把测试结果反馈给团队等干系人。
3. 测试用例很多重合
在面向终端用户的测试场景上，常规测试的用例与安全测试的用例是非常类似的。比如对于登录系统的功能，不管是常规测试还是安全测试，我们都会测试用户输入正确的用户名是否可以登录，输入错误的用户名或密码系统会如何反应。
比如我曾经工作的一个搜集报税人信息的系统，不管是常规测试还是安全测试，都会测试系统的登录，系统信息的录入与编辑，文件的上传等等。因为在每一个终端用户可以操作的场景上，都可能会有安全漏洞存在。所以，有了常规测试的经验，我们就相当于有了不少安全测试用例的储备。
4. 都需要有探索的过程
测试是一个了解软件系统能否完成我们预期的过程，也是探索系统还有哪些我们没有预期的行为的过程。安全测试的过程需要把探索的目标转向安全漏洞。当我们这么做时，我们同样会得到很多探索的乐趣。
5. 都要有测试人员必备的“怀疑态度”
相信咱们测试人员都非常熟悉一个场景－－开发人员说：“我只做了一个很小的代码改动。”然后我们带着友好而警惕的态度，发现这个“很小的改动”引发了很大的问题。不管是在安全测试还是非安全测试，这个警惕性是我们都需要保持的良好传统。
那么，有了这么多类似的地方，还缺什么呢？如果想要做专家，还差很多。但是如果想马上安全测试上起步，我们可以先做下面的改变。
3
安全测试从何做起
第一，转换视角
在我看来，不管是带着全栈的经验，还是只有部分技术知识，想要做好安全测试必须先转换我们观察软件的视角。举个例子，让我们看看下这幅画：
（图片来自：http://imgur.com/gallery/ZCgQ3）
同样一幅画，有人一眼看过去看到的是两个人脸，而有人看到的是一个花瓶。这就是观察视角的不同造成的。
在我刚开始接触安全测试时就很深的体会到了这一点。当时我在测试一个Web应用的用户登录功能。当我输入错误的用户名来试着登陆时，浏览器上的提示信息为“该用户名不存在”。当我尝试正确的用户名而错误的密码时，提示信息变成“密码输入错误。”对于这个清晰的错误提示我非常满意。试想我若是一个真实的终端用户，这个信息有效的帮助我缩小纠错范围，提高效率，非常好。
可是，就在我身边坐着的安全测试人员马上跳了出来：“这个提示信息需要改！敏感信息暴露了！”看到我一脸茫然，这位安全测试人员告诉我，通过我们的提示信息，恶意的系统使用者可以推测出哪些用户名已经存在于系统中，然后利用这些用户名可以再进行密码的暴力破解，缩小破解的范围。所以，这个信息虽然为合法用户提供了便利，也为不怀好意的系统使用者提供了便利。而往往这种便利为恶意的系统使用者带来的好处远大于给合法用户带来的好处。
这个经历在让我受震动的同时，也使我意识到可能很多安全漏洞之前就摆在我的面前了，我却没有看出来，因为我把它们过滤了。事实证明，在后来经历的不同项目中，当我转换了视角，有些安全漏洞不需要我去找，而是自己跑到我眼前来的。真是得来全不费功夫。
第二，改变测试中模拟的对象
为了能从不同的视角来观察软件，我们必须改变我们所模拟的对象。这也是一个让我们刻意练习转换视角的有效方法。
我们在做非安全测试的时候通常把自己想象成一个合法用户，然后开始验证系统是否能完成预设的目标。比如对于一个网上商城，我们会验证系统是否能让用户完成商品的浏览与购买，我们也会测试一些异常的行为，比如购买的商品数量不是数字而是一串无意义的字母时，看系统是否能比较优雅的做出回应。我们这么测试的目的往往是为了确保用户误操作以后还能够继续他们的购买，或者说不要给系统造成什么严重的伤害。
如果要做安全测试，我们则必须去模拟系统的另一类使用者－恶意用户。他们的目的是寻找系统中可钻的漏洞。比如同样是一个网上商城，恶意用户的目标之一就是要想办法以较少的钱，甚至不付钱就能拿到商品。所以，如果恶意用户进行了“误操作”，他们不会停留在“误操作”，而是通过“误操作”来看系统是否给自己提供更多的线索。
所以，我们需要转换测试时所模拟的对象，把思维从一个合法用户的视角中拉出来，转换成一个恶意用户。这需要一点时间，就如同之前看到的画，如果我们一开始看到的是人脸，要想下一次第一眼看到的是花瓶，我们需要时间来刻意练习。
第三，使用专用的测试工具
有了思维的转换，我们可以加入新的测试想法。但是，在具体做安全测试的时候我们会发现并不是那么容易去模拟恶意用户的行为。毕竟系统的前端会给我们设置很多的屏障。而且恶意用户可不总是从系统前门进去的。这时候，使用一些工具，比如OWASP Zap、Burp等是非常有帮助的。我们可以在系统界面上执行功能测试的用例，用这些工具来获取http请求，篡改后发送给后台服务器。有了这些实用又比较容易上手的工具，我们就可以执行很多恶意用户的操作场景了。
能做到这三点，起步就基本够用了。
4
举个栗子吧
