Question

本节我们将对开发安全应用程序的开发流程进行说明。以下说明中虽然都是以应用程序外包开发为例，但是自己公司内部开发时，除了角色担当不同之外，其所需要实施的内容都是一样的。

8.3.1　规划阶段的注意事项

在规划阶段非常重要的一件事就是要确保开发中和安全性相关的内容的预算。

要做预算的话必须先对安全性需求的整体内容进行讨论。把应用程序开发外包时，或者需要从外部调配安全产品时，可以在规划阶段制作 RFI（Request For Information，信息提供要求书），向承包商提供应用程序的概要和重要信息列表，并要求承包商提供关于提高系统安全性所需要的对策及大概的预算等信息。RFI 同时也可以作为对承包商的第一次审查，可以在这个阶段去评价承包商的意欲与能力。

8.3.2　招标时的注意事项

招标时会由发包方编写 RFP（Request For Proposal，需求建议书），让承包方据此进行估算并投标。关于安全性的功能需求也需要写在 RFP 中。由于 RFP 是进预算的前提，所以在 RFP 中明确记载安全性需求是非常重要的。

这里我们需要将安全性功能（需求）和安全性 Bug 分开考虑。首先安全性功能需求的成本投入和效果是成正比的，我们需要基于规划阶段的讨论结果来决定是否需要实现这些安全性功能并记录到 RFP 中。

另一方面，对安全性 Bug 的需求往往是很模糊的内容，即使记述到 RFP 中，如果不能通过测试来验证的话，也没有意义的。关于安全性 Bug，可以考虑像下面这样向承包商提出比较具体的要求。

• 列举出需对应的漏洞的名称
• 明确标明验收方法和验收标准
• 如果有需要追加的对策则要求承包商作出相应提案
• 要求承包商提供安全性能测试方法的说明，并将测试结果作为项目交付物提交
• 明确项目验收后发现的漏洞的应对方法及费用承担情况
• 要求承包商对开发体制做出说明
• 要求承包商提供开发标准和安全性测试报告书样本

专栏：谁应该对安全漏洞负责？

安全漏洞的责任在于发包方，还是承包方，这是个问题。笔者认为在这种将项目委托给承包方进行开发的体制中，风险的责任应该由发包方来承担。原因是需求文档是由发包方提供给承包方的，而且法律上也没有对关于开发的应用程序中出现漏洞时的责任做出明确的规定 1 。

另外，经济产业省刊发的《信息系统、交易模型与合同（模型合同）》[1] 中有以下的描述。

关于和本软件相关的安全方面的对策，包括具体的功能、遵守方法、管理体制以及费用承担等在其他条款另行约定（参考第 50 条）。当架构设计（系统设计）里包含安全性功能需求时，（发生的问题）则符合“与系架构设计不一致”，属于本条所描述的“缺陷”问题。

也就是说，系统设计文档里中没有明确记载的内容不能算作缺陷 2 。因此，站在发包方的立场考虑，为了自我保护就必须在合同和需求文档中明确标明安全性方面的要求。

那是不是承包方在客户没有明确提出安全上的相关需求时，就可以不做任何安全对策了呢？笔者并不这么认为。笔者认为至少要对安全漏洞采取必要的措施。作为承包方，即便是客户方没有明确要求，也应该对安全性的重要性进行说明，并努力让安全需求得到客户理解，并将其写入 RFP 中。所以，回答规划阶段 RFI 的安全性问题并强调其重要性是非常重要的。

1 个人信息保护法是针对 Web 应用的运营方（即发包方）的规定。并且软件不属于制造物责任法所限制的对象范围内。关于制造物责任法可以参考 http://www.consumer.go.jp/kankeihourei/seizoubutsu/pl-j.html

2 模型合同的“安全对策”指的就是本书所述安全性功能需求，而不是指安全性漏洞。

8.3.3　需求分析时的注意事项

在需求分析及以后的开发阶段，工作的主体就转换到承包方了。在需求分析中，也需要分别对安全性功能和安全漏洞进行整理。

首先，需要发包方在需求中对安全功性能进行定义。

其次，笔者建议在应对安全漏洞这个问题上以承包方（实际进行开发的公司）的开发标准为基础。如果不遵循开发公司平常所使用的标准的话，则需要对开发者进行再培训，这样必然导致开发成本上升。通过对比顾客的 RFP 或需求文档中所记载的安全要点和承包方的开发标准，进行匹配度分析，如果发现自己开发标准中不合适的地方则进行相应的补充，逐渐完善项目的开发标准（如图 8-2）。

图 8-2　以承包方的开发标准为基础做成的项目开发标准

在进行需求分析时，讨论重心除了上图 8-2 的内容之外，还应包括下述内容。

• 用户认证、账号管理、授权管理方面的需求（参考 5.1～5.3 节）
• 日志管理方面的需求（参考 5.4 节）
• 其他安全性功能需求
• 选择基础软件和确定打补丁的方法（参考 7.1.3 节）
• 分析开发标准和安全性需求间的差距

8.3.4　概要设计的推进方法

本节主要对概要设计的推进方法进行说明。安全性功能与普通的功能要点一样，只要严格执行瀑布式的设计、开发、测试就可以了。

关于安全性 Bug 的处理，我们要把需求分析时所确定的开发标准进行细化，一直细化到可直接写代码的水平，然后根据安全测试方法记录到架构设计书中。

在概要设计阶段需要实施的项目主要有以下几项。

• 对安全性功能进行细化
• 对开发标准进行细化，确定测试方法
• 在界面设计时对安全功能进行确认
  • 罗列出需要进行 CSRF 对策的页面
  • 罗列出需要使用 HTTPS 的页面

8.3.5　详细设计和编码阶段的注意事项

详细设计阶段之后的工作就是按照概要设计进行设计和开发。每个阶段都要进行设计评审、代码评审，以检查是否严格遵守了开发标准和开发方法。虽然评审过程可以省略，但我们在这里建议一定要执行评审过程。

8.3.6　安全性测试的重要性及其方法

无论是安全性 Bug 还是安全性功能需求，最终都要通过测试来验证开发出的产品是否满足需求。发包方也要在验收的时候进行安全性测试。

实施安全性测试（也可以称为漏洞检查、漏洞诊断）的方法有如下几种：

• 委托专家进行漏洞诊断
• 使用专业工具进行诊断
• 进行自我诊断

专家诊断的特点是检查精度高，漏洞导致的影响报告详细，但所花费成本比较高 3 。

3 本书都是基于实际情况写的，实际上各个专家厂商的能力和价格相差很大。

在 Web 应用程序漏洞检查工具中，比较有名的是 IBM 的 Rational AppScan，HP 的 HP WebInspect software 等 4 ，但这两个工具都需要至少数百万日元（相当于十几到数十万人民币）的初期投入。最近无论是承包公司还是发包公司，有越来越多的公司都用漏洞检查工具来对本公司的 Web 应用实施安全性测试。

4 还有三个开源软件也比较常用：
WebScarab: https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
OpenVAS: http://www.openvas.org/index.html
w3af: http://w3af.org/ ——译者注

关于最后的自我诊断方法，由于之前没有太多公开的关于安全测试的方法等信息，所以很多公司不知道如何去实施安全性测试。作为安全性诊断的方法，我们下面以地方自治信息中心发布的“Web 健康诊断基准”为例进行介绍。

8.3.7　Web 健康诊断基准

Web 健康诊断是地方自治信息中心（LASDEC）面向地方公共团体实施的 Web 网站进行的漏洞诊断。这是一种为了判断是否需要更精确的漏洞诊断而进行的一种简易检查方法。检查的基准公布在了 LASDEC 的主页（ https://www.j-lis.go.jp/lasdec-archive/cms/12,23183,84.html ）。

这个 Web 健康诊断基准可以广泛用来对 Web 应用进行安全性检查，其特征如下。

• 覆盖危险程度较高的 12 项漏洞
• 明确定义了诊断基准、判断标准、抽样标准
• 通过 Fiddler 等免费工具即可进行诊断
• 是以正式网站为对象，安全性较高的诊断基准
• 不对漏洞的影响程度和影响范围做判断
• 只是简易的检查，不做深度检查

下图 8-3 是 Web 健康诊断基准里面关于 SQL 注入攻击和跨站脚本攻击的检测示例。

图 8-3　Web 健康诊断基准

Web 健康诊断实际上是抽样检查，抽样标准也是公开的，使用这些检测模式就可以对应用程序做整体测试。图 8-4 是利用 Web 健康诊断基准进行的系统安全检查的示例。

如下图所示，利用 Web 健康诊断基准，在浏览器或者代理工具（Fiddler 等）里输入检测模式，通过确认服务器返回的应答来进行检查。这种检查不需要熟悉源代码或者了解内部构造，只使用了攻击者

图 8-4　利用 Web 健康诊断基准进行安全检查

8.3.8　承包方测试

尽管现在在开发过程中就进行安全性测试的团队还比较少，但笔者还是强烈建议在开发中就穿插进行安全性测试。

开发人员进行安全性测试主要有以下方法。

• 代码检查
• 使用工具进行黑盒测试
• 手动进行黑盒测试

这里我们将只对代码检查和手动进行黑盒测试进行说明。

代码检查可以通过目测或者使用查找工具（grep 等）进行 5 。因为从头到尾将代码通读一遍非常费时费力，所以我们可以以开发标准为基础确认开发是否遵守了该标准。代码检查比较适合发现以下几种潜在威胁。

5 也存在商用的代码自动检查攻击，本书里将不对此做出说明。

• SQL 注入漏洞
• 目录遍历漏洞
• OS 命令注入漏洞

上面这些服务器内部发生的漏洞，从外边是很难判断的，如果从代码级别来调查的话反而比较简单快捷。

手动黑盒测试的话，可以使用前面讲过的 Web 健康诊断的方法。系统安全隐患的很大一部分都可以以页面为单位进行测试，所以只要一个页面已经完成，就可以进行安全性测试了。提前开始实施安全性测试，会减少返工，有助于降低项目成本。

所以，综合上述几点，最好在系统架构设计的时候就制定安全测试的计划。

8.3.9　发包方测试（验收）

笔者见过很多在招标时明确将系统漏洞对策作为系统安全性功能需求的发包方，但是在验收时进行系统漏洞检测的发包方并不多见。实际上，在招标时已经明确定义的安全性功能需求，在验收时也需要认真验收。发包方如果提前告知承包商将进行安全性测试的话，会给承包商一些压力，也会让其加强体制，有一定的有利影响。

关于验收时的漏洞检测，可以使用以下方法。

• 审查承包商的安全测试报告（检查文档）
• 委托第三方（专家）进行测试
• 自行测试

第一种方法，由于发包方很难客观地检查承包商提供的文档，所以不推荐使用。第二种方法通过雇佣第三方来实施检测，这种方法虽然在检查精度和客观性上都很有保障，但是相应的成本也会增加。如果预算不多的话，则可以考虑利用 Web 健康诊断基准来自己进行安全测试的工作。

8.3.10　运维阶段的注意事项

发包方在验收了承包商的交付物之后，就进入运营、维护阶段了。在此阶段下面两项尤为重要。

• 对日志文件的监视
• 漏洞对策

另外，还需要一年进行一到两次 Web 网站健康诊断。之所以这么做是出于以下两个目的。

• 对上次诊断之后新增加的页面或者功能进行诊断
• 检查新出现的攻击方法的对策

日志监视的重要性已经在 5.4 节介绍过了。也可以通过 iLogScanner6 等日志分析工具来发现潜在的攻击行为。

6 iLogScanner 是独立行政法人信息处理推进机构免费发布的日志分析攻击，它会从日志里寻找 SQL 注入攻击等攻击的痕迹。 http://www.ipa.go.jp/security/vuln/iLogScanner/index.html

根据平台和应用的不同漏洞的对应方法也不一样。平台的漏洞可以参考 7.1 节介绍过的内容，随时关注各种安全漏洞，适时地实施安全对策（打补丁等）。

而就应用程序本身来说，发现系统漏洞的途径主要有以下几种。

• 定期 Web 健康诊断时发现的漏洞
• 从日志分析判断
• 外部报告的漏洞

不管是哪种情况，尽早发现并修补漏洞都是最重要的。为了方便地获取外部报告的漏洞，最好设置一个问题报告中心 7 。

7 漏洞报告中心的例子可以参考微软的安全技术中心。 http://technet.microsoft.com/zh-cn/security/ff852094