首页>>技术前沿>>网站/软件行业动态 
近来几年，很多大型网站频发安全事件，比如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。
二 ZAP分类
一类是比较有共性的，即可以抛开业务上下文，软件之间共通的一些问题，常见的比较严重的安全隐患，如XSS攻击，CSRF攻击等，ZAP可以帮我们扫描出大多数的问题。
另一类是针对业务需求的，比如非授权的账户是否不能访问/修改他们没有权限的信息等等，对于这一类问题，离开具体的业务上下文，是很难测试的，因为什么样的用户具有什么样的权限往往是业务领域的知识，换句话说，这一类问题的测试重点是看正常的用户能否按照业务需求所期望地正常使用系统，怎么区分evil user并阻止其对系统的使用和破坏，需要很强的业务背景。
举一个简单的例子，比如一个Web系统有两种角色，管理员和普通账户，业务需求是管理员可以修改所有人的所有信息，普通账户只能看到和修改自己的信息，如果普通账户张三可以通过一些非正常手段修改李四的信息，或者非系统的用户(evil user)通过某些方式可以看到系统内账户的个人信息，这些都是严重的安全缺陷，而且这一类的缺陷所占比率比较大，但是都没有办法通过ZAP扫描出来，也没有办法脱离对业务知识的了解来进行测试。
三 安全措施
1. 传统安全实践面临着严峻的挑战
随着互联网应用、移动应用爆发式的增长，伴随而来的黑客攻击事件也是层出不穷。仅在过去的2015年里，被公开报道的数据泄露安全事件就有约3930起，将近7.36亿条数据被泄漏。显而易见的是，如果某家企业被爆出安全问题，对企业造成的影响不仅仅只是名誉、财务上的损失，还会遭受法律诉讼，陷入竞争不利的局面。安全已经是企业不可忽视的问题。
近年来，黑客攻击的趋势已经发生了显著的改变，由最初的针对网络、操作系统以及服务器的攻击，已经转变为针对应用程序的攻击。根据Garnter的调研报告显示，有将近80%的安全漏洞发生在应用层。为了应对新的安全威胁，企业也做出了各种尝试，例如为员工提供安全培训、设立安全规范文档、部署Web应用防火墙、建立安全监控中心、利用安全渗透测试寻找安全漏洞等等。经过一些列的努力，取得的成果也是比较显著的，例如老生常谈的SQL注入攻击，其全球范围内的漏洞数量呈现出了非常显著的下降趋势，
2. 更好的解决安全问题
安全漏洞本质上是软件质量缺陷，安全性是软件质量的重要组成部分，而现如今应用安全面临的问题和多年以前软件测试面临的问题极其相似。当时人们在开发软件的时候，采取的做法往往是在软件开发临近结束之时集中性的进行测试，修复发现的质量缺陷，结果是当时的软件质量普遍不高，不少项目因此失败。
为了提高软件质量，开发团队采取了一些措施，例如将测试介入的时间点提前，尽早进行测试，甚至是先写测试后写实现代码，与此同时也大量采用自动化测试来加快测试执行速度，采用构建流水线持续关注软件质量，并且每位团队成员都对软件质量负责，而不再认为只是测试人员的职责。这些措施之所以能够显著提高软件质量，关键在于它们能够更加高效的为开发团队提供软件质量相关的反馈信息，使得开发团队能够基于反馈结果迅速进行改进。
同理，要更好的解决安全问题，开发团队应当建立起一个高效的安全反馈机制，在开发过程中引入一些安全活动，尽早开始收集安全反馈信息，加快获取安全反馈的速度，在整个开发过程中持续性的关注应用的安全性，与此同时团队成员共同来承担安全职责。我们将这些在实践中总结出来的经验命名为内建安全的软件开发方式（Build Security In DnA，下文简称BSI），从源头上尽早、尽快、持续性的，以团队共同协作的方式发现并解决安全问题。
2.1 尽早获取安全反馈
越早获取到安全反馈信息，越有利于开发团队以更低的成本将其修复。一个反面例子是，安全问题在早期就已经引入了，但是只能通过后期的渗透测试才能暴露出来，安全反馈信息经历了很长一段时间才能反馈给开发团队。与其依赖于后期的渗透测试，不如在开发过程当中引入一些适当的安全实践，比如在分析业务需求的同时主动分析安全需求，将其作为质量验收标准在团队内明确出来，再比如，针对每次代码提交都对其进行安全评审、测试人员在测试业务功能的同时还对安全性进行验证。通过这种方式，使得团队能够尽快得知应用的安全状况，而不必依赖于很晚才能提供安全反馈的渗透测试。
2.2 通过自动化加速获取安全反馈的速度
从安全角度对代码进行的评审，以及测试人员主动进行安全测试等等手段都能更早的产出安全性的反馈信息，但是传统的安全测试、渗透测试主要是以手动的方式进行，造成的结果是需要耗费许多时间才能收集到安全反馈信息。更好的做法是，对于常规的安全测试可以借助工具以自动化的方式进行，不仅能够以更快的速度得到安全性反馈，还能在一定程度上弥补由于人员安全技能不足所造成的安全测试不够全面的问题。自动化带来的另外的好处是，它可以集成入CI服务器，从而让开发团队可以在CI流水线完成之后第一时间发现应用的常规安全问题，而不必等到上线前由安全专家来发现安全问题。
例如，应用通常依赖于各种第三方组件，这些组件可能含有已知的安全漏洞，手工对每个组件进行安全检查是行不通的，更好的做法是利用自动化的检查工具如OWASP Dependency Check，以更快的速度对组件进行安全检查并且生成结果报告。这一过程是完全自动化的，开发团队只需定期检查报告即可，使得开发团队获取反馈的速度得到极大的提升。
2.3 在开发过程中持续性的关注安全
收集安全反馈不是一次性的活动，高效的安全反馈机制和持续集成秉持相同的理念：除了尽早集成、尽快集成之外，很重要的一点就是让集成活动能够持续性的发生。类似的，对于建立高效的安全反馈机制而言，在能够尽早、快速的获取安全反馈的同时，还需要让这个反馈循机制在应用开发过程中持续的运行下去。
自动化使得开发团队能够更容易的做到对安全的持续关注。例如，将自动化的代码安全扫描和持续集成服务器结合起来，这样在每次代码提交后都能得到一份安全报告，从而可以立刻着手进行相应的修复。此外，对于那些不适合自动化运行的安全实践而言，开发团队依然有必要持续性的去做。例如，每当应用的功能发生变更之时都应该进行一次威胁建模以分析安全威胁，明确安全需求，每当新的功能被开发出来，测试人员都要对其安全性进行验证。
【全文完】
版权声明:
1、陕西弈聪网站内容中凡注明“来源：XXX（非陕西弈聪网站）”的作品，转载自其它媒体，转载目的在于传递更多信息，其中涉及的网站建设，网站优化，百度关键词优化，西安软件开发等技术细节并不代表本站赞同支持其观点，并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有，任何人转载请署名来源，否则陕西弈聪将追究其相关法律责任。
2、本站内容中未声明为“原创”的内容可能源自其它网站，但并不代表本站支持其观点，对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益，请联系我方进行删除。
企业动态
