近来几年，许多大型网站频发安全事情，比方2011年众所周知的CSDN暗码走漏事情，2014年eBay也因遭到进犯形成用户暗码和个人数据走漏，Web安全逐步进入人们的视界，安全测验也逐步成为了软件测验中十分重要的一部分。

说到安全测验，许多人应该都会想到ZAP，ZAP(Zed Attack Proxy)是OWASP供给的一款免费Web安全缝隙扫描东西，用户能够经过设置浏览器和ZAP的Proxy，在开发进程或测验进程中主动检测Web应用程序是否存在安全缝隙，ZAP还会供给扫描成果的危险等级，修正主张以及一些参阅文档，下图便是ZAP扫描后的一个用户界面。

除了主动扫描功用，ZAP也支撑手动安全测验，经过在数据发送到服务器之前手动修正恳求信息来测验Web应用程序是否存在安全缝隙。

许多人会有这样的疑问，ZAP能否扫描出一切的安全缝隙？ZAP扫描出的安全缝隙和安全等级是否牢靠？用了ZAP，软件是不是就安全了？

ZAP局限性

首要尽管ZAP的主动扫描功用十分强壮，但关于OWASP Top 10中的某些项或许Top 10以外的一些安全缝隙，想要经过ZAP扫描检测出来是十分困难的，比方Top 10中的A5 “Security Misconfiguration” 就很难经过扫描检测出来，所以ZAP所能扫描到的安全缝隙只是OWASP Top 10的一个子集。

其次，ZAP扫描后的安全陈述，仍是需求结合实践项目进行剖析才干确认其有效性和安全等级，比方咱们在项目中从前用ZAP扫描出了 “Cookie set without HttpOnly flag” 的安全隐患，引荐的处理方案是将一切的Cookie都设置成HttpOnly，但实践的状况是项目中前端AJAX需求带着这个Cookie来给后端发送恳求，假如设置了这个flag，那么咱们正常的恳求也会失利，所以这个缝隙对咱们来说便是无效的，或许说咱们是不应该修正的。

别的由于Web应用程序往往比较复杂，会有许多组成部分，比方前端、服务器端、数据库等，各层别离运用了不同的结构、言语，并且经常会引进一些第三方的库、结构或许模块，每一个环节都有或许存在安全隐患，所以只是依靠ZAP是不行的,比方针对第三方组件的安全测验，就能够凭借OWASP供给的别的一款东西Dependency Check。

经过剖析实践项目中发现的安全问题,咱们发现缺点大体上如下散布:

安全问题能够归为两大类：

一类是比较有共性的，即能够抛开事务上下文，软件之间共通的一些问题，常见的比较严峻的安全隐患，如XSS进犯，CSRF进犯等，ZAP能够帮咱们扫描出大多数的问题。 另一类是针对事务需求的，比方非授权的账户是否不能拜访/修正他们没有权限的信息等等，关于这一类问题，脱离详细的事务上下文，是很难测验的，由于什么样的用户具有什么样的权限往往是事务范畴的常识，换句话说，这一类问题的测验重点是看正常的用户能否依照事务需求所希望地正常运用体系，怎样区别evil user并阻挠其对体系的运用和损坏，需求很强的事务布景。

举一个简略的比方，比方一个Web体系有两种人物，管理员和一般账户，事务需求是管理员能够修正一切人的一切信息，一般账户只能看到和修正自己的信息，假如一般账户张三能够经过一些非正常手法修正李四的信息，或许非体系的用户(evil user)经过某些 *** 能够看到体系内账户的个人信息，这些都是严峻的安全缺点，并且这一类的缺点所占比率比较大，可是都没有 *** 经过ZAP扫描出来，也没有 *** 脱离对事务常识的了解来进行测验。

安全内建

ZAP扫描，针对事务上下文的用户权限测验（不能局限于界面，还要经过其他一些 *** 比方修正恳求）以及evil user的用户场景测验，能够掩盖绝大多数的Web安全缺点，可是正如咱们没有 *** 将质量注入一个现已成型的产品相同，安全也是相同的道理。

假如咱们在软件现已编码完结之后再引进安全查看和测验，那么软件的安全质量现已确认，后期的修正只能处理现已发现的安全缝隙，不能让软件愈加安全，并且关于这些安全缺点，发现得越晚，修正的本钱就会越高。

所以为了开发安全质量较高的产品，除了挑选好的东西以及添加事务布景下的安全测验，还十分有必要将安全查看和测验提早，在软件开发各个进程中引进安全实践。

微软提出的SDL(Security Development Lifecycle)便是这样的理念，SDL提出了许多软件开发进程中十分好的的安全活动，比方需求剖析阶段的“最小权限准则”，开发阶段“弃用不安全的函数”，以及测验阶段能够运用“含糊测验”等等，其核心理念便是将软件安全的考虑集成在软件开发的每一个阶段，从需求，规划，编码，测验，到最后的发布整个进程中，下图是一个简化版的SDL流程图,完好的SDL还包含前期的培训,发布后的呼应等:

[1] [2]  黑客接单网