作者：马伟

马伟，ThoughtWorks高级咨询师，长期从事企业级软件开发工作，拥有丰富的应用开发经验，并在工作中积累了丰富的Web应用安全经验。目前专注于安全技术的创新与实践，热衷于探索和研究各种Web应用漏洞，对如何将安全实践集成到敏捷开发流程中有浓厚的兴趣和深入的实践。

第三方组件安全剖析

马伟 评论

Apache Struts2再曝高危漏洞

前段时间，Apache Struts2又接连曝出了两个高危远程代码执行（Remoce Code Execution，下文简称RCE）漏洞（CVE-2017-5638）。为什么要说“又”呢？那是因为这早就不是Apache Struts2第一次曝出这类漏洞了。

你应该还有印象，早几年前Apache Struts2披露了一系列RCE漏洞，而且他们家在披露RCE漏洞的同时还附带了证明漏洞存在的POC（Proof Of Concept）脚本。在那次事件中，由于POC包含的信息量太大，其本意可能是想方便开发者了解更多漏洞细节，但未曾想却为黑客攻击提供了重要线索，不得不让人觉得是“神助攻”。再加上，这种做法几乎就没给使用Struts2的开发团队留出进行修复的时间，以至于在短时间里，国内外众多使用Struts2的网站，包括一些知名网站均遭到黑客攻击，大量网站纷纷表示躺枪。

前端JS框架、库的安全性同样令人担忧

如果说现如今Struts2在新开发的应用中的使用量小到几乎可以忽略不计，它的安全漏洞所带来的影响有限，那么当下火爆的各种前端JavaScript开发框架、库当中也存在安全漏洞这一事实却让情况变得不容乐观。

早在2014年，当时的一份调查研究发现，在Alexa排名前10万的网站中，有60%的网站使用了至少含有一个已知安全漏洞的JavaScript库。时间来到2017年，美国波斯顿Northeastern University做了一次跟进调查，发现Alexa排名前13万的网站中，有37%的网站使用了至少含有一个已知安全漏洞的JavaScript库。

挑战

使用含有已知安全漏洞的第三方组件的现象为何会如此普遍呢？原因是多方面的，比如，在采用第三方组件的时候没有对其进行安全检查，或者最初该组件并没有安全漏洞，只是随着时间推移，一段时间后被发现存在安全问题并披露了出来等等。要想扭转这一局面，开发团队却也面临着不小的挑战。

挑战一：第三方组件及其版本号众多，需要快速确认哪些存在已知安全漏洞，是否受到漏洞披露的影响

无论是服务器端应用还是运行在浏览器里的前端应用，使用几十个第三方组件、库是稀疏平常的事情，更何况这还只是直接依赖的第三方组件，要是算上间接依赖（即第三方组件所依赖的第三方组件，以此类推）的话，组成一个应用的第三方组件数量将会相当可观。

在知道应用所使用的所有第三方组件之后，还需要知道各个组件的精确版本号，然后才能将组件、版本号在已知漏洞数据库里进行匹配查询，得出最后的结果。

让问题变得更加棘手的是，一个企业里往往有不止一个应用系统，而每个系统都需要定期或者不定期的做这样的排查，所需要的工作量有多么巨大可想而知。

挑战二：和时间赛跑，需要在第一时间内得到通知，以最短时间完成修复和测试，并发布到生产环境

应用在还未发布时如果遇到这类问题，开发团队有充足的时间来做出应对，但对于已经处于运营中的应用而言，时间就是生命线，这是一场和黑客争分夺秒的战争，如果不能赶在黑客进行攻击前完成修复、发布等一系列任务，那就只能祝你好运了。

挑战三：对企业持续交付能力是个考验

在第三方组件的提供商披露安全漏洞的同时，还会给出修复建议，而通常的情况是，开发团队只需要将受到影响的第三方组件升级到新版本即可。看上去这似乎一点不难，但却细思极恐。

第一，版本升级可能会带来兼容性问题，导致应用无法正常启动、使用等。解决兼容性问题就可能得花去不少时间。

第二，迈过了兼容性这一关，开发团队还得对应用进行回归测试，以确保版本升级没有破坏原有的业务功能。那么问题来了，你的团队需要花多少时间进行这一测试呢？几分钟？几小时？还是几天甚至几周？

第三，开发团队排除重重困难，避开了兼容性问题，完成了回归测试，终于走到了发布修复这一步。此时，你的团队是否能对应用进行蓝绿部署、滚动发布以保证生产环境业务不会因为部署而中断？

解决之道

创建和维护第三方组件信息库

开发团队可以将应用中所使用到的所有第三方组件，包括那些间接依赖的第三方组件，及其版本号集中收集起来，形成一个组件信息库。于是，每当有第三方组件安全漏洞信息披露出来的时候，开发团队都可以立即做出判断，了解自己的应用是否受此次漏洞披露的影响。

定期匹配排查

除了在得到第三方组件安全漏洞的信息披露通知后进行识别判断，开发团队还非常有必要主动的对所用到的组件进行定期安全检查。因为在上一步中已经识别出了所有的第三方组件及其版本号，开发团队接下来需要做的，是将这些信息在已知安全漏洞数据库（例如National Vulnerability Database）中进行匹配。

自动化

刚才已经提到，识别第三方组件及其版本号，并且还要对其进行细致的匹配排查，工作量是非常巨大的，如果没有自动化的帮助，仅仅依靠人工的话，几乎是不可能完成的任务。

幸运的是，目前已经有不少工具能帮我们完成这一工作，例如两次入选ThoughtWorks技术雷达的OWASP Dependency Check，它能自动完成第三方组件识别、漏洞数据库维护，以及漏洞匹配、生成检查报告等一些列活动。除了支持Java和.Net应用外，还支持Ruby、NodeJS以及Python应用，以及部分C/C++应用。

同类型的工具还有支持.NET的OWASP SafeNuGet，专门针对Node应用的Node Security Project等等。对于其他语言，也有各自对应的自动化检查工具，在此就不一一列举了。

贯穿整个生命周期

在应用开发过程中，第三方组件可能会不断的被加入到项目里，或者移除出去，其版本也可能会随着时间的推移而不断更改。在这个过程中，组件的的每一次变化都可能会带来新的安全隐患。

开发团队可以利用上一步提到的自动化检查工具，并将其和CI服务器集成起来，可以很容易做到在每次代码提交的时候进行一次安全检查，从而达到持续监控组件安全性的目标。

总结

应用往往使用了大量第三方组件，它们可能含有安全漏洞，给应用的整体安全性埋下隐患。开发团队和黑客一直都在进行时间竞赛，其必须要在第一时间内得到安全漏洞的披露通知，赶在黑客发动攻击之前，完成漏洞修复工作。

好在开发团队可以利用各种自动化工具，快速且全面的发现那些有问题的第三方组件，通过运行回归测试以确保原有业务行为的正确性，并且结合持续交付的能力，在不影响生产环境业务持续运行的情况下，将代码改动发布到生成环境，及时避免第三方组件安全漏洞给应用带来安全风险。

更多精彩洞见，请关注微信公众号：思特沃克

Share

8大前端安全问题（下）

马伟 评论

在《8大前端安全问题（上）》这篇文章里我们谈到了什么是前端安全问题，并且介绍了其中的4大典型安全问题，本篇文章将介绍剩下的4大前端安全问题，它们分别是：

  • 防火防盗防猪队友：不安全的第三方依赖包
  • 用了HTTPS也可能掉坑里
  • 本地存储数据泄露
  • 缺乏静态资源完整性校验

防火防盗防猪队友：不安全的第三方依赖包

现如今进行应用开发，就好比站在巨人的肩膀上写代码。据统计，一个应用有将近80%的代码其实是来自于第三方组件、依赖的类库等，而应用自身的代码其实只占了20%左右。无论是后端服务器应用还是前端应用开发，绝大多数时候我们都是在借助开发框架和各种类库进行快速开发。

这样做的好处显而易见，但是与此同时安全风险也在不断累积——应用使用了如此多的第三方代码，不论应用自己的代码的安全性有多高，一旦这些来自第三方的代码有安全漏洞，那么对应用整体的安全性依然会造成严峻的挑战。

（图片来自：http://t.cn/RlAQsZ0）

举个例子，jQuery就存在多个已知安全漏洞，例如jQuery issue 2432，使得应用存在被XSS攻击的可能。而Node.js也有一些已知的安全漏洞，比如CVE-2017-11499，可能导致前端应用受到DoS攻击。另外，对于前端应用而言，除使用到的前端开发框架之外，通常还会依赖不少Node组件包，它们可能也有安全漏洞。

手动检查这些第三方代码有没有安全问题是个苦差事，主要是因为应用依赖的这些组件数量众多，手工检查太耗时，好在有自动化的工具可以使用，比如NSP(Node Security Platform)，Snyk等等。

用了HTTPS也可能掉坑里

为了保护信息在传输过程中不被泄露，保证传输安全，使用TLS或者通俗的讲，使用HTTPS已经是当今的标准配置了。然而事情并没有这么简单，即使是服务器端开启了HTTPS，也还是存在安全隐患，黑客可以利用SSL Stripping这种攻击手段，强制让HTTPS降级回HTTP，从而继续进行中间人攻击。

问题的本质在于浏览器发出去第一次请求就被攻击者拦截了下来并做了修改，根本不给浏览器和服务器进行HTTPS通信的机会。大致过程如下，用户在浏览器里输入URL的时候往往不是从https://开始的，而是直接从域名开始输入，随后浏览器向服务器发起HTTP通信，然而由于攻击者的存在，它把服务器端返回的跳转到HTTPS页面的响应拦截了，并且代替客户端和服务器端进行后续的通信。由于这一切都是暗中进行的，所以使用前端应用的用户对此毫无察觉。

解决这个安全问题的办法是使用HSTS（HTTP Strict Transport Security），它通过下面这个HTTP Header以及一个预加载的清单，来告知浏览器在和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信：

Strict-Transport-Security: max-age=<seconds>; includeSubDomains; preload

这里的“强制性”表现为浏览器无论在何种情况下都直接向服务器端发起HTTPS请求，而不再像以往那样从HTTP跳转到HTTPS。另外，当遇到证书或者链接不安全的时候，则首先警告用户，并且不再让用户选择是否继续进行不安全的通信。

（图片来自：http://t.cn/Rfj3Tku）

本地存储数据泄露

以前，对于一个Web应用而言，在前端通过Cookie存储少量用户信息就足够支撑应用的正常运行了。然而随着前后端分离，尤其是后端服务无状态化架构风格的兴起，伴随着SPA应用的大量出现，存储在前端也就是用户浏览器中的数据量也在逐渐增多。

前端应用是完全暴露在用户以及攻击者面前的，在前端存储任何敏感、机密的数据，都会面临泄露的风险，就算是在前端通过JS脚本对数据进行加密基本也无济于事。

举个例子来说明，假设你的前端应用想要支持离线模式，使得用户在离线情况下依然可以使用你的应用，这就意味着你需要在本地存储用户相关的一些数据，比如说电子邮箱地址、手机号、家庭住址等PII（Personal Identifiable Information）信息，或许还有历史账单、消费记录等数据。

尽管有浏览器的同源策略限制，但是如果前端应用有XSS漏洞，那么本地存储的所有数据就都可能被攻击者的JS脚本读取到。如果用户在公用电脑上使用了这个前端应用，那么当用户离开后，这些数据是否也被彻底清除了呢？前端对数据加密后再存储看上去是个防御办法，但其实仅仅提高了一点攻击门槛而已，因为加密所用到的密钥同样存储在前端，有耐心的攻击者依然可以攻破加密这道关卡。

所以，在前端存储敏感、机密信息始终都是一件危险的事情，推荐的做法是尽可能不在前端存这些数据。

缺乏静态资源完整性校验

出于性能考虑，前端应用通常会把一些静态资源存放到CDN（Content Delivery Networks）上面，例如Javascript脚本和Stylesheet文件。这么做可以显著提高前端应用的访问速度，但与此同时却也隐含了一个新的安全风险。

如果攻击者劫持了CDN，或者对CDN中的资源进行了污染，那么我们的前端应用拿到的就是有问题的JS脚本或者Stylesheet文件，使得攻击者可以肆意篡改我们的前端页面，对用户实施攻击。这种攻击方式造成的效果和XSS跨站脚本攻击有些相似，不过不同点在于攻击者是从CDN开始实施的攻击，而传统的XSS攻击则是从有用户输入的地方开始下手的。

防御这种攻击的办法是使用浏览器提供的SRI（Subresource Integrity）功能。顾名思义，这里的Subresource指的就是HTML页面中通过<script>和<link>元素所指定的资源文件。

每个资源文件都可以有一个SRI值，就像下面这样。它由两部分组成，减号（-）左侧是生成SRI值用到的哈希算法名，右侧是经过Base64编码后的该资源文件的Hash值。

<script src=“https://example.js” integrity=“sha384-eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX”></script>

浏览器在处理这个script元素的时候，就会检查对应的JS脚本文件的完整性，看其是否和script元素中integrity属性指定的SRI值一致，如果不匹配，浏览器则会中止对这个JS脚本的处理。

小结

在上一篇和本篇文章中，我们为大家介绍了在开发前端应用的时候容易遇到的8大安全问题，它们是：

  • 老生常谈的XSS
  • 警惕iframe带来的风险
  • 别被点击劫持了
  • 错误的内容推断
  • 防火防盗防猪队友：不安全的第三方依赖包
  • 用了HTTPS也可能掉坑里
  • 本地存储数据泄露
  • 缺乏静态资源完整性校验

我们希望能通过对这些问题的介绍，引起前端开发小伙伴的注意，尽可能提前绕过这些安全问题的坑。

更多精彩洞见，请关注微信公众号：思特沃克

Share

8大前端安全问题（上）

马伟 3 条评论

当我们说“前端安全问题”的时候，我们在说什么

“安全”是个很大的话题，各种安全问题的类型也是种类繁多。如果我们把安全问题按照所发生的区域来进行分类的话，那么所有发生在后端服务器、应用、服务当中的安全问题就是“后端安全问题”，所有发生在浏览器、单页面应用、Web页面当中的安全问题则算是“前端安全问题”。比如说，SQL注入漏洞发生在后端应用中，是后端安全问题，跨站脚本攻击（XSS）则是前端安全问题，因为它发生在用户的浏览器里。

除了从安全问题发生的区域来分类之外，也可以从另一个维度来判断：针对某个安全问题，团队中的哪个角色最适合来修复它？是后端开发还是前端开发？

总的来说，当我们下面在谈论“前端安全问题”的时候，我们说的是发生在浏览器、前端应用当中，或者通常由前端开发工程师来对其进行修复的安全问题。

8大前端安全问题

按照上面的分类办法，我们总结出了8大典型的前端安全问题，它们分别是：

  • 老生常谈的XSS
  • 警惕iframe带来的风险
  • 别被点击劫持了
  • 错误的内容推断
  • 防火防盗防猪队友：不安全的第三方依赖包
  • 用了HTTPS也可能掉坑里
  • 本地存储数据泄露
  • 缺失静态资源完整性校验

由于篇幅所限，本篇文章先给各位介绍前4个前端安全问题。

老生常谈的XSS

XSS是跨站脚本攻击（Cross-Site Scripting）的简称，它是个老油条了，在OWASP Web Application Top 10排行榜中长期霸榜，从未掉出过前三名。XSS这类安全问题发生的本质原因在于，浏览器错误的将攻击者提供的用户输入数据当做JavaScript脚本给执行了。

XSS有几种不同的分类办法，例如按照恶意输入的脚本是否在应用中存储，XSS被划分为“存储型XSS”和“反射型XSS”，如果按照是否和服务器有交互，又可以划分为“Server Side XSS”和“DOM based XSS”。

无论怎么分类，XSS漏洞始终是威胁用户的一个安全隐患。攻击者可以利用XSS漏洞来窃取包括用户身份信息在内的各种敏感信息、修改Web页面以欺骗用户，甚至控制受害者浏览器，或者和其他漏洞结合起来形成蠕虫攻击，等等。总之，关于XSS漏洞的利用，只有想不到没有做不到。

如何防御

防御XSS最佳的做法就是对数据进行严格的输出编码，使得攻击者提供的数据不再被浏览器认为是脚本而被误执行。例如<script>在进行HTML编码后变成了&lt;script&gt;，而这段数据就会被浏览器认为只是一段普通的字符串，而不会被当做脚本执行了。

编码也不是件容易的事情，需要根据输出数据所在的上下文来进行相应的编码。例如刚才的例子，由于数据将被放置于HTML元素中，因此进行的是HTML编码，而如果数据将被放置于URL中，则需要进行URL编码，将其变为%3Cscript%3E。此外，还有JavaScript编码、CSS编码、HTML属性编码、JSON编码等等。好在现如今的前端开发框架基本上都默认提供了前端输出编码，这大大减轻了前端开发小伙伴们的工作负担。

其他的防御措施，例如设置CSP HTTP Header、输入验证、开启浏览器XSS防御等等都是可选项，原因在于这些措施都存在被绕过的可能，并不能完全保证能防御XSS攻击。不过它们和输出编码却可以共同协作实施纵深防御策略。

你可以查阅OWASP XSS Prevention Cheat Sheet_Prevention_Cheat_Sheet)，里面有关于XSS及其防御措施的详细说明。

警惕iframe带来的风险

有些时候我们的前端页面需要用到第三方提供的页面组件，通常会以iframe的方式引入。典型的例子是使用iframe在页面上添加第三方提供的广告、天气预报、社交分享插件等等。

iframe在给我们的页面带来更多丰富的内容和能力的同时，也带来了不少的安全隐患。因为iframe中的内容是由第三方来提供的，默认情况下他们不受我们的控制，他们可以在iframe中运行JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端用户体验。

如果说iframe只是有可能会给用户体验带来影响，看似风险不大，那么如果iframe中的域名因为过期而被恶意攻击者抢注，或者第三方被黑客攻破，iframe中的内容被替换掉了，从而利用用户浏览器中的安全漏洞下载安装木马、恶意勒索软件等等，这问题可就大了。

如何防御

还好在HTML5中，iframe有了一个叫做sandbox的安全属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则。使用sandbox的最简单的方式就是只在iframe元素中添加上这个关键词就好，就像下面这样：

<iframe sandbox src="..."> ... </iframe>

sandbox还忠实的实现了“Secure By Default”原则，也就是说，如果你只是添加上这个属性而保持属性值为空，那么浏览器将会对iframe实施史上最严厉的调控限制，基本上来讲就是除了允许显示静态资源以外，其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等，连Origin都会被强制重新分配一个唯一的值，换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。

另外，sandbox也提供了丰富的配置参数，我们可以进行较为细粒度的控制。一些典型的参数如下：

  • allow-forms：允许iframe中提交form表单
  • allow-popups：允许iframe中弹出新的窗口或者标签页（例如，window.open()，showModalDialog()，target=”_blank”等等）
  • allow-scripts：允许iframe中执行JavaScript
  • allow-same-origin：允许iframe中的网页开启同源策略

更多详细的资料，可以参考iframe中关于sandbox的介绍。

别被点击劫持了

有个词叫做防不胜防，我们在通过iframe使用别人提供的内容时，我们自己的页面也可能正在被不法分子放到他们精心构造的iframe或者frame当中，进行点击劫持攻击。

这是一种欺骗性比较强，同时也需要用户高度参与才能完成的一种攻击。通常的攻击步骤是这样的：

  1. 攻击者精心构造一个诱导用户点击的内容，比如Web页面小游戏
  2. 将我们的页面放入到iframe当中
  3. 利用z-index等CSS样式将这个iframe叠加到小游戏的垂直方向的正上方
  4. 把iframe设置为100%透明度
  5. 受害者访问到这个页面后，肉眼看到的是一个小游戏，如果受到诱导进行了点击的话，实际上点击到的却是iframe中的我们的页面

点击劫持的危害在于，攻击利用了受害者的用户身份，在其不知情的情况下进行一些操作。如果只是迫使用户关注某个微博账号的话，看上去仿佛还可以承受，但是如果是删除某个重要文件记录，或者窃取敏感信息，那么造成的危害可就难以承受了。

如何防御

有多种防御措施都可以防止页面遭到点击劫持攻击，例如Frame Breaking方案。一个推荐的防御方案是，使用X-Frame-Options：DENY这个HTTP Header来明确的告知浏览器，不要把当前HTTP响应中的内容在HTML Frame中显示出来。

关于点击劫持更多的细节，可以查阅OWASP Clickjacking Defense Cheat Sheet。

错误的内容推断

想象这样一个攻击场景：某网站允许用户在评论里上传图片，攻击者在上传图片的时候，看似提交的是个图片文件，实则是个含有JavaScript的脚本文件。该文件逃过了文件类型校验（这涉及到了恶意文件上传这个常见安全问题，但是由于和前端相关度不高因此暂不详细介绍），在服务器里存储了下来。接下来，受害者在访问这段评论的时候，浏览器会去请求这个伪装成图片的JavaScript脚本，而此时如果浏览器错误的推断了这个响应的内容类型（MIME types），那么就会把这个图片文件当做JavaScript脚本执行，于是攻击也就成功了。

问题的关键就在于，后端服务器在返回的响应中设置的Content-Type Header仅仅只是给浏览器提供当前响应内容类型的建议，而浏览器有可能会自作主张的根据响应中的实际内容去推断内容的类型。

在上面的例子中，后端通过Content-Type Header建议浏览器按照图片来渲染这次的HTTP响应，但是浏览器发现响应中其实是JavaScript，于是就擅自做主把这段响应当做JS脚本来解释执行，安全问题也就产生了。

如何防御

浏览器根据响应内容来推断其类型，本来这是个很“智能”的功能，是浏览器强大的容错能力的体现，但是却会带来安全风险。要避免出现这样的安全问题，办法就是通过设置X-Content-Type-Options这个HTTP Header明确禁止浏览器去推断响应类型。

同样是上面的攻击场景，后端服务器返回的Content-Type建议浏览器按照图片进行内容渲染，浏览器发现有X-Content-Type-OptionsHTTP Header的存在，并且其参数值是nosniff，因此不会再去推断内容类型，而是强制按照图片进行渲染，那么因为实际上这是一段JS脚本而非真实的图片，因此这段脚本就会被浏览器当作是一个已经损坏或者格式不正确的图片来处理，而不是当作JS脚本来处理，从而最终防止了安全问题的发生。

更多关于X-Content-Type-Options的细节请参考这里。

小结

本文对前端安全问题进行了一次梳理，介绍了其中4个典型的前端安全问题，包括它们发生的原因以及防御办法。在下篇文章中，我们将介绍其他的几个前端安全问题，敬请期待。

更多精彩洞见，请关注微信公众号：ThoughtWorks商业洞见

Share

持续交付模式下的安全活动

马伟 评论

在上一篇文章《开发团队面临的三大安全挑战》中，我们对现如今敏捷精益团队所面临的安全挑战进行了总结和分析，这三大挑战分别是：

  1. 一次性的安全检查无法匹配持续性的交付模式
  2. 缺乏自动化、自助化的支持，安全实践落地难
  3. 高耸的部门墙让开发和安全团队难以进行高效的协作

在接下来的几篇文章中，我们将逐一为你介绍团队、组织应该如何应对这些挑战。本篇文章先来讲讲如何解决第一个挑战。

采用持续性的、轻量级的，能够融入到持续交付模式的安全活动

对于绝大多数团队而言，为了确保开发出来的应用具有足够的安全性，渗透测试是一个被广泛采用的手段，也可以说是唯一依赖的手段。然而由于渗透测试比较重量级，通常只能提供一次性的安全反馈，而这在追求快速开发、迅速响应市场变化的敏捷精益开发方式下，它的不足被放大了。

团队需要的是一个高效的安全质量反馈机制。所谓“高效”是指，这个机制必须能以更快的速度、更高的频率提供应用的安全质量反馈，并且要足够轻量级以便于无缝融入到迭代交付过程中。

那么“更快”是多快？多频繁才算“更高的频率”？“轻量级”要轻到什么程度？

快到“立等可取”，比如只需几分钟甚至更少时间，就能知道应用的安全质量如何；频繁到任意时刻都可以获取一次安全质量反馈，比如每次代码提交后，都能知道应用安全质量是否被破坏；轻量级到团队不认为这些安全活动会带来多大的额外付出，比如每日代码审查中，顺便从安全的角度对代码进行评审，就能阻止有安全风险的代码被提交到代码仓库，而整个过程可能只多花费了几分钟时间而已。

一些推荐采用的安全活动

在CI中集成自动化安全扫描工具

其实在很早以前大家就已经发现，凭借人工的力量从应用里寻找安全漏洞异常耗时，另外对于某些安全漏洞，完全可以通过特征识别的方式对脚本来自动进行检测，于是从那时起就诞生了一系列自动化安全扫描工具，以下简称“漏扫工具”。

与此同时，在应用开发这件事情上，持续集成、持续交付的理念也在迅速的被广泛接纳，越来越多的团队开始使用CI，也体会到了自动化的威力所带来的好处。

随着CI的广泛普及，团队完全可以把这些漏扫工具集成到CI当中，作为应用构建过程中的一个标准步骤来执行。这样，团队既可以借助漏扫工具以节约人工成本，又可以持续性的对应用安全质量进行监控：一旦某次构建发现安全问题，构建流水线就会失败，引起开发团队的注意，促使团队尽快对有问题的代码进行修复，从而降低漏洞修复成本。

漏扫工具数量众多，可以说是百家争鸣，不过可惜的是，易于集成到CI中的却不多。OWASP ZAP提供了RESTful API，也有Jenkins插件，算是做得比较不错的漏扫工具，而BurpSuite要做到同样的效果还需要额外的配置才行。推荐团队可以先尝试把ZAP集成到CI中。关于具体的集成细节，我们会通过后续文章进行介绍。

编写自动化安全功能性测试用例

漏扫工具不是全能的，有些类型的安全漏洞，比如身份认证、访问控制以及和业务强相关的漏洞，它就很难甚至根本无法扫出来。然而，这些漏扫工具不容易扫出来的安全漏洞，对于人来讲却正好是小菜一碟。

举个例子，人能够很好的理解下面这个API应当具备的安全行为，并对其进行有针对性的测试，然而漏扫工具则已经哭晕在厕所：

漏扫工具检查不出来的安全问题，人可以很好的进行测试，并且依然通过自动化来提高效率。团队可以像平常编写集成测试，或者端到端功能性测试那样，对于期望应用应当具备的安全行为，编写对应的测试用例进行覆盖。我们把这种做法叫做编写自动化安全功能性测试用例。

随着自动化安全功能性测试用例数量的不断累积，它的威力也将越来越明显，尤其是在对应用进行回归测试的时候，更是显露无疑。通常而言，在团队每次做应用发布之前，都会进行一次回归测试，主要目的是确认新功能工作正常，与此同时已有功能未被破坏。安全作为应用质量中的重要组成部分，也应该进行一次回归测试。相比于传统的渗透测试，自动化安全功能性测试用例再配合上CI中的自动化漏扫工具，在很短的时间里就能对应用进行比较全面的安全检查，为应用发布提供决策支持。

识别安全需求，并将其作为验收标准写入到用户故事卡

如果说把漏扫工具集成到CI，以及编写自动化安全功能性测试用例是在“把事情做对”，那么识别安全需求，并把它作为验收标准写入到用户故事卡中则是在“做正确的事情”。

团队其实是很重视安全的，他们愿意付出努力提升应用的安全性，然而这又和我们实际观察到的现状有冲突：安全的事情大家心知肚明，但就是没人主动去做。

为什么？原因是多方面的，其中一个重要的原因是，因为安全需求没有被明确提出来，它既不在故事卡的验收标准里，也没有在给故事卡估点的时候被考虑进去。于是安全需求就仿佛变成了“多出来的”工作量，一旦团队面临交付压力，这部分工作自然就会被无限期的往后推迟，最后的归宿就是不了了之。

因此，团队除了需要借助漏扫工具以及自动化安全性功能测试用例，还需要把安全需求明确出来，纳入到项目交付范围内。团队可以用威胁建模、恶意攻击场景头脑风暴等活动来梳理安全需求。

此外需要注意的是，安全需求的表现形式不是最重要的，最关键的在于把需求在团队内部明确出来，而不是大家心照不宣。比如，安全需求是写入到故事卡的验收标准里，还是单独创建安全故事卡，这本身并不重要，重要的是安全需求通过这些形式能得到明确，让团队能把安全需求和常规的业务需求一起放到Backlog里，统一对它们估点、设置优先级、安排迭代交付计划。

小结

敏捷精益团队面临的第一大安全挑战就是一次性的安全检查无法匹配持续性的交付模式。应对这一挑战，团队需要采用一系列持续性的、轻量级的，能够融入到持续交付模式的安全活动，从而使得团队建立起一个高效获取应用安全质量反馈的机制。

至于敏捷精益团队如何应对另外两大安全挑战，我们将在后续的文章里一一详解，敬请期待。

更多精彩洞见，请关注微信公众号：思特沃克

Share

开发团队面临的三大安全挑战

马伟 评论

应用安全不能只依靠防火墙，必须要在应用开发阶段采取适当的安全控制措施，使得应用在发布上线前就具备较好的安全性，避免人为失误造成安全隐患。

不少企业早就意识到了这一点，然而理想和现实之间还隔着几十个安全漏洞，尤其是那些采用敏捷或者精益开发模式的团队，在具体的实践过程中，几乎无可避免的会遭遇到下面几个挑战。

挑战1：一次性的安全检查无法匹配持续性的交付

为确保团队开发出来的应用具有足够的安全性，最常见的选择是对其进行全方位的安全渗透测试。无论这样的测试是由企业自己的安全团队执行，还是购买外部第三方服务，最终都会得到一份详细的安全报告，团队接下来需要做的就是基于这份报告所揭露的漏洞，对应用进行相应的调整，直到安全漏洞被修复为止。

持续交付是敏捷、精益开发团队的核心能力之一，这意味着团队可以做到每周甚至任意时刻发布产品，持续性的从真实环境中获取市场反馈，然后基于这些反馈对产品进行调整。一个可以参考的案例是，早在2014年的时候，亚马逊平均每秒有一次以上的产品部署，每天如此。

与此同时，安全渗透测试却没有这么高的“交付”速度。由于渗透测试的特殊性，虽然有大量的自动化漏洞扫描工具可以使用，但是一次全面、高质量的渗透测试依然需要人工参与，几天甚至一两周之后才能得到测试报告是普遍现象。

那么问题来了，一方面开发团队持续性的每周都有新功能上线和旧功能调整，另一方面渗透测试却没办法在这么短的时间里完成，它只能是阶段性、或者定期性的进行，例如每个季度测试一次。

这种情况下，开发团队该何去何从？如果要安全，那么就得等着做渗透测试，而且一旦发现安全漏洞还要花额外的时间去修复，产品发布必定会延期。如果要效率，那么就只能冒着风险发布，因为谁也不知道当前应用有没有安全漏洞，万一被黑客发现并且加以利用，后果不堪设想。

问题的关键在于，开发团队是在持续的发布应用到生产环境，然而渗透测试却是个相当耗时的一次性活动，它没办法跟上这么快的交付速度。

挑战2：缺乏自动化、自助化的支持，安全实践落地难

开发团队其实明白安全对于应用而言至关重要，也知道在开发过程中就应当通过运用各种安全最佳实践来主动消除安全问题，把安全风险降至最低。不过现状却是，不少安全实践要么无法落地实施，要么有流于形式的倾向。

一个真实的案例

一个开发团队在做完业务需求梳理后，立即进入了开发阶段。安全团队虽然在项目启动时提出过安全要求，例如要求团队采用威胁建模活动，识别出应用面临的安全威胁，并制定应对措施。然而由于该项目交付压力大，时间紧任务重，再加上团队成员对于威胁建模并不熟悉，最后这个活动被一拖再拖，直到应用开发完毕进行上线前的审批时，才发现没有做威胁建模，而此刻为了能让应用按时上线，只好回过头来临时补一份威胁建模的文档，仅用于应付安全部门的要求。这种情况下，安全威胁根本得不到全面的分析和应对，风险由此而生。

在项目前期的设计阶段是进行威胁识别的最佳时刻，开发团队只要在这时做一次威胁建模，就能识别出潜在的安全风险，并且在接下来的开发过程中采取适当的措施加以应对。但是开发团队却仿佛是懒癌晚期患者，硬是拖到上线前才把威胁建模补上，而此时它早已失去意义。

为何开发团队一边认同安全的重要性，一边却又对安全实践如此怠慢呢？本质原因在于，某些安全实践需要大量人工参与，或者对人员安全技能有很高的要求，与此同时又缺乏自动化、自助化的支持，因此在开发团队看来，这些实践的采纳成本太高，在面临交付压力的情况下选择性的忽略，或者认认真真的走个形式，就成了再正常不过的结果。

挑战3：高耸的部门墙让开发和安全团队难以进行高效的协作

随着敏捷、精益开发模式的普及，再加上DevOps转型的助推，不少企业已经开始组建全功能开发团队，团队中各个角色有着共同的目标，相互协作以更高的效率交付应用。但是安全团队却依然隶属于一墙之隔的安全部门。

别小看了这堵墙，说它是万恶之源有点太夸张，但它的存在确确实实阻碍了企业实现其业务价值最大化。墙的这边，开发团队竭尽所能的以最快的速度完成应用开发，以求尽快上线获取反馈；墙的另一边，安全团队只关心应用是否安全，至于是否急着上线，那不是他们关心的问题。但是他们都忽略了一个事实，那就是企业的成功需要两者共同高效的协作。

小结

敏捷、精益团队一方面要保持快速的交付速度，一方面还要提高应用的安全质量，看上去这是鱼和熊掌不可兼得的事情，然而事实上我们依然有办法解决这些挑战。

开发团队可以通过自动化，显著降低安全实践的实施难度和成本，把一次性的安全检查转变为持续性的安全质量反馈。对于安全团队，也应当向着开发团队迈进一步，打通开发和安全部门之间的隔离，以更加紧密和高效协作的方式，共同确保应用具备更高的安全质量。

更多精彩洞见，请关注微信公众号：思特沃克

Share