《白帽子讲Web安全》17-18章

《白帽子讲Web安全》17-18章

17、安全开发流程（SDL）

17.1、SDL简介

SDL 的全称是 Security Development Lifecycle，即：安全开发生命周期。它是由微软最早提出的，在软件工程中实施，是帮助解决软件安全问题的办法。SDL是一个安全保证的过程，其重点是软件开发，它在开发的所有阶段都引入了安全和隐私的原则。

微软的 SDL过程大致分为16个阶段（优化后）。

• 阶段1：培训
  开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识。培训的环节在SDL中看似简单，但其实不可或缺。通过培训能贯彻安全策略和安全知识，并在之后的执行过程中提高执行效率，降低沟通成本。培训对象包括开发人员、测试人员、项目经理、产品经理等。

  微软推荐的培训，会覆盖安全设计、威胁建模、安全编码、安全测试、隐私等方面知识。

• 阶段2：安全要求
  在项目确立之前，需要提前与项目经理或者产品 owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布——这是任何项目经理都讨厌发生的事情。

• 阶段3：质量门/bug栏
  质量门和 bug栏用于确定安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全 bug。项目团队必须协商确定每个开发阶段的质量门（例如，必须在check in代码之前进行review并修复所有的编译器警告)，随后将质量门交由安全顾问审批，安全顾问可以根据需要添加特定于项目的说明，以及更加严格的安全要求。另外，项目团队需阐明其对安全门的遵从性，以便完成最终安全评析（FSR)。

  bug 栏是应用于整个软件开发项目的质量门，用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。bug 栏一经设定，便绝不能放松。

• 阶段4：安全和隐私风险评估
  安全风险评估（SRA）和隐私风险评估（PRA）是一个必需的过程，用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息：

  1. （安全）项目的哪些部分在发布前需要威胁模型?
  2. （安全）项目的哪些部分在发布前需要进行安全设计评析?
  3. （安全）项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试?
  4. （安全）是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险?(5)(安全）模糊测试要求的具体范围是什么?
  5. （隐私）隐私影响评级如何?

• 阶段5：设计要求
  在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求尽可能避免安全引起的需求变更。

• 阶段6：减小攻击面
  减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能地进行分层防御。

• 阶段7：威胁建模
  为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。微软提出了STRIDE模型以帮助建立威胁模型，这是非常好的做法。

• 阶段8：使用指定的工具
  开发团队使用的编译器、链接器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。

• 阶段9：弃用不安全的函数
  许多常用函数可能存在安全隐患,应该禁用不安全的函数或API，使用安全团队推荐的函数。

• 阶段10：静态分析
  代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合。

• 阶段11：动态程序分析
  动态分析是静态分析的补充，用于测试环节验证程序的安全性。

• 阶段12：模糊测试（Fuzzing Test）
  模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试，或者扩大模糊测试的范围和增加持续时间。

• 阶段13：威胁模型和攻击面评析
  项目经常会因为需求变更等因素导致最终的产出偏离原本设定的目标，因此在项目后期重新对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。

• 阶段14：事件响应计划
  受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。需要注意的是，如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。

• 阶段15：最终安全评析
  最终安全评析（FSR）是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同结果。

  • 通过 FSR。在 FSR过程中确定的所有安全和隐私问题都已得到修复或缓解。
  • 通过 FSR但有异常。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来，在下次发布时更正。
  • 需上报问题的FSR。如果团队未满足所有SDL 要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的问题，或者上报高级管理层进行抉择。

• 阶段16：发布/存档
  在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但反巾的同的时而刈合尖问题和文档进行存档,为紧急响应和产品升级提供帮助。

17.2、敏捷SDL

敏捷SDL的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化，代码可能也在发生变化，这要求在实施SDL时需要在每个阶段更新威胁模型和隐私策略，在必要的环节迭代模糊测试、代码安全分析等工作。

17.3、SDL实战经验

准则一：与项目经理进行充分沟通，排出足够的时间。
准则二：规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏。
准则三：树立安全部门的权威，项目必须由安全部门审核完成后才能发布
准则四：将技术方案写入开发、测试的工作手册中。
准则五：给工程师培训安全方案。
准则六：记录所有的安全 bug，激励程序员编写安全的代码。

17.4、需求分析与设计阶段

需求分析阶段与设计阶段是项目的初始阶段。需求分析阶段将论证项目的目标、可行性、实现方向等问题。

在需求阶段，安全工程师需要关心产品主要功能上的安全强度和安全体验是否足够，主要需要思考安全功能。比如需要给产品设计一个“用户密码取回”功能，那么是通过手机短信的方式取回，还是邮箱取回？很多时候，需要从产品发展的大方向上考虑问题。

在需求分析阶段，可以对项目经理、产品经理或架构师进行访谈，以了解产品背景和技术架构，并给出相应的建议。从以往的经验来看，一份checklist可以在一定程度上帮助到我们。

此外，在项目需求分析或设计阶段，应该了解项目中是否包含了一些第三方软件。如果有，则需要认真评估这些第三方软件是否会存在安全问题。很多时候，入侵是从第三方软件开始的。

17.5、开发阶段

开发阶段是安全工作的一个重点。依据“安全是为业务服务”这一指导思想，在需求层面，安全改变业务的地方较少，因此应当力求代码实现上的安全，也就是做到“安全的功能”。

17.5.1、提供安全的函数

如果开发者没有把握实现一个足够好的安全模块，则最好是参考OWASP ESAPI的实现方式。

在开发阶段，还可以使用的一个最佳实践就是制定出开发者的开发规范，并将安全技术方案写进开发规范中，让开发者牢记开发规范。

将安全方案写入开发规范中，就真正地让安全方案落了地。这样不仅仅是为了方便开发者写出安全的代码，同时也为代码安全审计带来了方便。

17.5.2、代码安全审计工具

实际上，对于甲方公司来说，完全可以根据开发规范来定制代码审计工具。其核心思想是，并非直接检查代码是否安全，而是检查开发者是否遵守了开发规范。

这样就把复杂的“代码自动化审计”这一难题，转化为“代码是否符合开发规范”的问题。而开发规范在编写时就可以写成易于审计的一种规范。最终，如果开发规范中的安全方案没有问题的话，当开发者严格遵守开发规范时，产出的代码就应该是安全的。

17.6、测试阶段

安全测试应该独立于代码审计而存在。“安全测试”相对于“代码审计”而言，至少有两个好处：一是有一些代码逻辑较为复杂，通过代码审计难以发现所有问题，而通过安全测试可以将问题看得更清楚；二是有一些逻辑漏洞通过安全测试，可以更快地得到结果。

安全测试，一般分为自动化测试和手动测试两种方式。

• 自动化测试以覆盖性的测试为目的，可以通过“Web安全扫描器”对项目或产品进行漏洞扫描。
  目前Web安全扫描器针对“XSS”、“SQL Injection”、“Open Redirect”、“PHP File Include”等漏洞的检测技术已经比较成熟。这是因为这些漏洞的检测方法主要是检测返回结果的字符串特征。

• 而对于“CSRF”、“越权访问”、“文件上传”等漏洞，却难以达到自动化检测的效果。这是因为这些漏洞涉及系统逻辑或业务逻辑，有时候还需要人机交互参与页面流程。因此这类漏洞的检测更多的需要依靠手动测试完成。

安全测试完成以后，需要生成一份安全测试报告。这份报告并不是扫描器的扫描报告。扫描报告可能会存在误报与漏报，因此扫描报告需要经过安全工程师的最终确认。确认后的扫描报告，结合手动测试的结果，最终形成一份安全测试报告。

安全测试报告中提到的问题，需要交给开发工程师进行修复。漏洞修补完成后，再迭代进行安全测试，以验证漏洞的修补情况。由此可见，在项目初期与项目经理进行充分沟通，预留出代码审计、安全测试的时间，是一件很重要的事情。

17.7、小结

本章讲述了如何在项目开发的过程中实施SDL（安全开发流程)。SDL是建立在公司软件工程基础之上的，公司的软件工程实施越规范，SDL就越容易实施，反之则难度越大。

SDL需要从上往下推动，归根结底，它仍然是“人”的问题。实施SDL一定要得到公司技术负责人与产品负责人的全力支持，并通过完善软件发布流程、工程师的工作手册来达到目的。SDI实施的成功与否，与来自高级管理层的支持力度有很大关系。

18、安全运营

18.1、把安全运营起来

互联网公司如何规划自己的安全蓝图呢?从战略层面上来说，Aberdeen Group提到了三句话: Find and Fix，Defend and Defer，Secure at the Source。

• 一个安全评估的过程，就是一个“Find and Fix”的过程。通过漏洞扫描、渗透测试、代码审计等方式，可以发现系统中已知的安全问题;然后再通过设计安全方案实施安全方案，最终解决这些问题。

• 而像入侵检测系统、Web应用防火墙，反DDOS设备等则是一些防御性的工作，这也是保证安全必不可少的一个部分。它们能防范问题于未然，或者当安全事件发生后，快速地响应和处理问题。这些防御性的工作，是一个“Defend and Defer”的过程。

• 最后“Secure at the Source”指的则是“安全开发流程(SDL)"，它能从源头降低安全风险，提高产品的安全质量。

这三者的关系是互补的，当 SDL出现差错时，可以通过周期性的扫描、安全评估等工作将问题及时解决；而入侵检测、WAF等系统，则可以在安全事件发生后的第一时间进行响应，并有助于事后定损。如果三者只剩其一，都可能使得公司的安全体系出现短板，出现可乘之机。

安全运营贯穿在整个体系之中。安全运营需要让端口扫描、漏洞扫描、代码白盒扫描等发现问题的方式变成一种周期性的任务。

“Fix”的工作分为两种:一种是例行的扫描任务发现了漏洞，需要及时修补;另一种则是在安全事件发生时，或者是Oday漏洞被公布时，需要进行紧急响应。这些工作需要建立制度和流程，并有专门的人对此负责。

18.2、漏洞修补流程

对于“安全运营”的工作来说，建立漏洞修补流程，意味着需要完成这几件事情：

• (A）建立类似 bugtracker的漏洞跟踪机制，并为漏洞的紧急程度选择优先级；
• (B）建立漏洞分析机制，并与程序员一起制定修补方案，同时 review补丁的代码实现；
• (C）对曾经出现的漏洞进行归档，并定期统计漏洞修补情况。

对存在过的漏洞进行归档，是公司安全经验的一种积累。历年来曾经出现过的漏洞，是公司成长的宝贵财富。对漏洞数量、漏洞类型、产生原因进行统计，也可以从全局的角度看到系统的短板在什么地方，为决策提供依据。

18.3、安全监控

安全监控与报警，是“Defend and Defer”的一种有效手段。

18.4、入侵检测

常见的安全监控产品有IDS（入侵检测系统)、IPS（入侵防御系统)、DDOS监控设备等。在 IDS这个大家族中，Web应用防火墙（简称WAF）又是近年来兴起的一种产品。相对于传统的IDS来说，WAF专注于应用层攻击的检测和防御。

18.5、紧急响应流程

常见的报警方式有三种。

• (1) 邮件报警
• (2) IM（Instant Messaging）报警
• (3) 短信报警

建立紧急响应流程，首先要建立“紧急响应小组”，这个小组全权负责对紧急安全事件的处理、资源协调工作。小组成员需要包括:
技术负责人产品负责人

• 最了解技术架构的资深开发工程师
• 资深网络工程师
• 资深系统运维工程师
• 资深DBA
• 资深安全专家
• 监控工程师
• 公司公关

当安全事件发生时，首先应该通知到安全专家，并由安全专家召集紧急响应小组，处理相关问题。在处理安全问题时，有两个需要注意的地方。
一是需要保护安全事件的现场。从以往的经验看，很多时候由于缺乏安全专家的指导，安全事件的现场往往被工程师破坏，这对后续分析入侵行为以及定损带来了困难。

当入侵事件发生时，首先不要慌张，应该先弄清楚入侵者的所有行为都有哪些，然后评估入侵事件所造成的损失。比较合理的做法是先将被入侵的机器下线，在线下进行分析。

二是以最快的速度处理完问题。紧急响应流程启动后，就是与时间争分夺秒，因此务必在最短的时间内找到对应的人，并制定出相应的计划，很多流程能省则省。这也是为何需要让技术负责人、产品负责人，以及各个领域的资深工程师加入的原因。紧急响应小组的成员，一定要是最了解公司业务和架构的人，这样才能快速定位和解决问题。

18.6、小结

安全运营实施的好坏，将决定公司安全是否能健康地发展。只有把安全运营起来，在变化中对抗攻击，才能真正让安全成为一个持续的过程，才能走在正确的道路上。