ibm测试工具APPSCAN的web安全性测试1

network

IBM Rational AppScan Enterprise Edition 护驾企业 Web 应用安全，第 1 部分：企业级 Web 应用安全解决方案介绍及其特点

文档选项 打印本页 将此页作为电子邮件发送 赵静, 技术顾问, IBM 2008 年 9 月 28 日 本文分为两部分，第一部分将从 Web 应用安全解决方案的演进入手，探究解决方案的发展之路，并对文中称之为“战略方法”的企业级解决方案及其特点进行深入分析；在第二部分中，将从开发人员、安全管理员、经理等角色出发，用实例的形式展示出使用统一的管理平台后，给企业安全管理带来的方便性、统一性和其它优势。 前言 近年来，随着 Web 应用的普及，企业都争先恐后的提供 Web 平台，或者作为信息发布的门户，用以扩大企业的知名度；或者将部分甚至全部业务放到互联网上，吸引更多的客户，增加企业的收益。有了对外的窗口，在吸引广大用户的同时，企业 Web 应用也受到黑客们的频频光顾。从 2006 年至今，许多著名网站被黑客攻击的消息屡见报端，从发布信息的政府网站、到各类运营商网站，甚至是在线交易的银行网站，都难于幸免。虽然大部分黑客只是为了显示其成就感，在网站上留下“到此一游”的痕迹，但是对于将重要数据放在 Web 应用上的企业来说，他们的系统安全、产品质量乃至企业的资质都受到了严重的质疑。 值得庆幸的是，目前大部分企业都已经意识到了 Web 应用安全的重要性，他们在探索、寻求能够协助企业构筑安全应用的解决方案，而且，他们中的一部分，也对应用安全进行了更为深入的思考，如何在软件开发的整个生命周期中保证其 Web 应用的安全？ 回页首 Web 应用安全解决方案的演进 我们对任何事物的了解，都是一个从无意识到有意识、从有意识到深刻认识的过程，应用安全也不例外。图 1 很好的说明了 Web 应用安全解决方案的演进。 1、在早期，开发的应用（包括 Web 应用），人们普遍看重其功能、性能、可访问性等方面，而且当时由于黑客数量少、网络未广泛普及、上网条件限制等因素，应用的安全性也确实没有显示出其危害性。因此，在相当长的一段时间内，安全性都没有被纳入系统质量评估的范畴。在这里，我们称之为“无意识”时期。 图 1 Web 应用安全解决方案演进 2、平静的网络世界被日益猖獗的黑客打破，一些网站受到了侵犯，在损失钱财的同时，企业的资质也经受着严重的考验。但此时，企业中并没有专门的安全审计部门，没有人为系统的安全负责。因此，一些咨询公司抓住契机，将业界从事于安全研究的人员招至旗下，开始向具有 Web 应用的企业提供安全诊断服务。这种咨询通常按照次数来收费，定期或不定期的扫描企业 Web 应用。在这里，我们称之为“外包解决”时期。将安全审核外包，对于企业中没有安全专家、无法内部审核的状况而言，在一定程度上解决了企业的问题。但这种方案也存在着弊端，比如：系统安全完全依赖于外部，没有自主权；定期诊断的周期之间，系统仍然存在被黑客攻击的风险；企业安全漏洞数据掌握在他人手中等等。 “外包解决”方案，由于其方便快捷，至今仍然拥有众多客户，和后面的“战术方法”将会存在相当长的并行期。 3、由于“外包解决”方案存在的弊端，一部分企业开始注重培养内部的人才，组建系统安全小组，或者在质量管理（QA）部门中添置相关人员担任此项工作。安全小组通常使用人工检测和桌面工具相结合的方法，在系统上线前进行安全诊断，是企业中系统安全的“把关者”和“救火队员”。这一时期，我们称之为“战术方法”阶段。目前国内大部分有应用安全意识的企业，都逐渐从“外包解决”时期向“战术方法”过渡。笔者在另一篇文章中，详细探讨了使用桌面工具的“战术方法”，请参见“使用 Rational AppScan 保证 Web 应用的安全性”一文。 4、成立安全小组，有专人为应用安全负责，相比之前已经有相当大的进步。然而，整个企业的应用安全，将仅仅依赖于某个小组，甚至是二、三个人。这对于一些拥有多个 Web 应用、对应用安全又非常看重的大型企业来说，无法在整个企业内部、在整个软件开发周期中，让负责项目的每一个成员都参与到应用安全的保证中来。这就是我们即将要提到的“战略方法”。该阶段强调在企业内建立完整的应用安全机制，从系统开发、系统构建、测试、到上线前后，都可以建立应用安全的保证措施；对系统安全的诊断，不同部门、不同角色、甚至不同地域的分支机构，都可以在统一的平台上进行协作；同时，对于安全数据这样敏感的信息，又可以在企业内部，按照权限、按照组织，方便的控制或流转。 随着应用安全解决方案的发展，让企业中的每个人都拥有应用安全意识、在系统开发的每个阶段都能保证安全，将成为应用安全发展的必然之路。 回页首 “战略方法”－企业级解决方案介绍 企业级应用安全平台应具备的能力 工欲善其事，必先利其器。要想建立企业级的 Web 应用安全解决方案，除了需要一套严格的流程和制度之外，功能完备、先进的平台也同样不可或缺。一个在企业内行之有效的平台应该具备如下特征： 统一管理、多用户访问的能力 具备统一入口的平台，可以作为企业安全应用的接入中心，方便每个人员访问，包括跨地域工作的组织和部门；多用户访问，可以最大化的利用该平台，让所有人员都可以方便的参与到应用安全的建设中来。 全面的应用安全覆盖能力 能将企业中所有 Web 应用纳入统一的平台进行诊断分析和管理，能最大化的统一利用企业内部的软、硬件资源，做到平衡负载、并行处理大量应用的同时扫描和诊断。 丰富的报告和缺陷管理能力 对不同的应用进行安全扫描之后，可以生成内容丰富的各种报告及报表。由于应用安全涉及企业内部核心敏感数据，因此报告的生成和分发，应该在权限上有所控制。同时，面对企业的不同角色，报表及报告应该可以自行定制，根据用户角色选择不同侧重点生成。 在应用中发现的任何安全缺陷，应该纳入企业的缺陷和变更管理系统。通过提供内置的流程管理功能或者和企业现有的变更管理系统集成，所有安全缺陷可以方便的在企业内部进行状态转换。 强大的权限管理能力 应用安全漏洞是企业的核心数据，即便在企业内部泄漏也存在着被攻击和利用的风险。因此，集中控制和管理的企业级应用安全平台，应该具有强大的权限管理功能。 该功能应该涵盖两个层面，一是控制企业用户使用平台的权限，也就是控制不同角色的用户可以使用平台的何种功能；二是安全隐患数据依据何种权限进行分发，也就是什么角色的用户应该看到平台产生的哪些数据。 灵活的软、硬件部署能力 根据企业规模和硬件架构的不同，企业级应用安全平台应该可以灵活部署，并能在任何部署模式下，进行系统负载平衡、优化系统并行处理能力。 回页首 IBM Rational 企业级应用安全解决方案阐述 IBM Rational 企业级应用安全解决方案，以 AppScan Enterprise Edition（以下简称为 ASE）作为核心平台。ASE 是构建在桌面产品 Rational AppScan 的先进技术之上，基于 Web 的多用户访问系统，可以协助企业对其大量的 Web 应用进行安全管理。 3.2.1 ASE 基本概念 1. 工作原理 ASE 在对 Web 应用进行安全扫描时，采用了一种称之为“黑盒扫描”的技术，在工作原理上和桌面产品 AppScan 相同。 图 2 ASE 扫描 Web 应用原理－黑盒扫描 如图 2 所示， ASE 系统就像普通用户浏览网站一样，并不关心 Web 应用内部的技术架构（如使用何种语言编写等），只是将应用看做黑盒。它从网站的主页（home page）或者用户指定的任何一页开始，遍历所有链接。根据每一页面的特点，ASE 会使用多种测试参数，对页面进行分析。这些测试参数以 HTTP 请求的形式发送，并通过返回的 HTTP 响应来决定应用中是否存在安全漏洞。ASE 有数以千计的内置测试参数，可以检测出百余种漏洞。 2. 扫描范围 保障应用安全，有很多层面，如下图 3 所示的安全栈结构。在这之中，ASE 可以覆盖 Web 服务器、Web 服务器配置、第三方组件和 Web 应用本身以及 Web Services。 图 3 安全栈结构及 ASE 扫描范围 ASE 能够测试的漏洞类型，以国际组织“Web 应用安全委员会（WASC）” Threat Classification 项目中定义的 6 大类、24 小类为基础，再加上经过多年实践经验总结的部分私有测试用例，形成了一套完整的、行之有效的漏洞库，并及时更新，以确保 Web 应用扫描结果的全面性。 表 1 列举了 WASC 的 Web 应用漏洞分类，每类漏洞的详细信息请参见如下地址 http://www.webappsec.org/projects/threat/ 表 1 － WASC Threat Classification 3．数据流分析 在详细解释 ASE 内部的数据流之前，需要先了解几个关键术语： Content Scan Job（内容扫描任务）：内容扫描任务负责遍历和测试网站的页面，从中发现安全隐患。该任务使用任务管理员（Job Administrator）设定的参数。 Infrastructure Scan Job（结构扫描任务）：结构扫描任务用来收集应用的技术架构信息。它使用一系列 IP 地址作为输入，扫描对应的端口。也就是说，它遍历企业中的每一个 IP 地址，检查其对应的主机。如果发现了一台主机，该任务就会使用参数中指定的所有端口来判断这台主机是否为 Web 服务器。如果是，ASE 将收集该 Web 服务器的版本、SSL 认证、允许的 HTTP 方法等信息。 Import Job（导入任务）：导入任务负责数据格式的整合，比如将 AppScan 桌面版的 XML 格式文件，导入到 ASE 中加以利用。 Report Pack（报告包）：报告包是生成报告的集合，可以按照任何选择的的标准进行组织，如按照 Web 应用、按照开发人员、按照业务部门等组合报告。 Dashboard（仪表板）：仪表板跟踪并总结企业 Web 应用的问题和趋势。它回答了以下相关人员关心的问题：企业中应用的总体安全水平如何？有哪些 Web 应用需要多加注意其安全性？在企业中哪些安全问题出现的频率最高？应该告诉开发团队哪些需要特别注意的安全隐患？ Folder（文件夹）：文件夹是仪表板、扫描任务、报告包的容器，它可以帮助你按照需要的逻辑来组织信息。 有了上述基本概念，就可以更好的理解 ASE 中的数据流。如图 4 所示，在 ASE 中，用户选择执行不同的任务，比如扫描应用、数据导入、扫描系统架构等，这些任务会从应用中分别收集相关数据，并把它们存储在 ASE 的数据库中；报告引擎分析数据库中的数据，生成不同类型的报告。需要说明的是，扫描和生成报告被设计成两个独立的进程，这就可以让用户从不同的任务中选择数据，生成更为详细的、跨任务内容的报告；各种生成的报告，以报告包的形式组织，这样在逻辑上更合理些；仪表板将报告包中的报告数据集合起来，以提供更高层面上的统计和总结信息。 从上述数据流可以看出，最基本的数据来源是任务，只有执行相应的任务，得到了返回的数据内容，才能根据这些内容组织成报告；只有生成了各种类型的报告，仪表板才能根据已有的报告包组织出不同的仪表板内容。 图 4 ASE 中的数据流 3.2.2 ASE 安全解决方案特点 如果说桌面产品 AppScan，其工作重心就是扫描、测试、分析具体 Web 应用的话，那 ASE 除了具备 AppScan 所有能力之外，还具有桌面产品无法匹敌的如下特点： 1. 基于 Web 的多用户安全解决方案 完整的应用覆盖度：基于服务器（server-based）的扫描引擎，其处理能力可以保证正确无误的测试企业中成百上千个 Web 应用，并同时对这些应用进行分析和处理。 由于 ASE 可以根据企业的需要进行灵活的架构搭建和系统配置（这一点我们将在本章节第 4 部分中讲到），因此图 5 仅表示 ASE 系统架构的主要组件。 图 5 ASE 的系统组件概览 在企业中，所有人员都是通过 Web 界面来访问和使用 ASE 的，该界面就存储在 ASE Control Center Server 上，它由一组 ASP.net 页面组成。由图 5 可以看到，渗透测试人员、开发人员、安全管理组、质量保证团队等各种角色，都是通过 ASE Control Center 访问系统、并得到最后的扫描结果。根据用户量，企业可以部署多台 Control Center，进行负载平衡。 ASE Database Server 是另一个重要的组件，它通过使用 SQL Server 等商业关系型数据库，存储了所有 ASE 的配置数据，如用户信息、扫描配置、报告配置等；同时，它也存储了在应用安全扫描过程中收集的所有数据。数据库组件可以被配置成集群，以保证更好的负载平衡和冗余。 ASE Agent Server 负责真正的安全漏洞扫描工作。它由一组 Windows 进程组成，负责访问目的 Web 应用，并把扫描过程中的所有信息记录在数据库中。一个 Agent Server 可以同时扫描多个 Web 应用，通过增加 Agent Server 的数量，企业可以实现同时测试多个应用的目的。 广泛的人员参与度：ASE 通过统一的 Web 界面，可以让尽可能多的角色参与到应用安全管理中来，如图 6 所示。 图 6 ASE 具有广泛的人员参与 ASE 的最新版本中，包含了集成的在线培训模块。在该培训中，用户不但可以学习 ASE 的使用方法和相关产品知识，还可以了解 Web 应用的安全常识、多种著名漏洞的攻击原理、各种漏洞的详细说明等，大大方便了企业将安全意识贯彻到各个角色的日常工作中。 ASE 中还包含了一个快速的测试工具 QuickScan。QuickScan 是一个简化的扫描方法，它将忙碌的开发人员从复杂的应用安全中解脱出来。由于经过管理员事先定义扫描模板，开发人员不需要在客户端进行安装或做任何配置，就可以直接使用。扫描结果组织成任务列表形式，开发人员不需要成为安全专家，只需要根据任务列表去相应的代码处进行修改即可。 2. 提供丰富报告的应用安全平台 在 3.2.1 章节中，我们描绘了 ASE 中的数据流，也引出了报告、报告包、仪表板等概念。ASE 中提供了 7 种类型的报告，每种类型又可以细分为多种子类型，涵盖了应用安全所涉及的方方面面，在这里我们简述部分重要的报告。 安全报告 应用安全报告：列出了在扫描中发现的所有应用安全隐患，包括隐患的数量、类型、存在隐患的具体链接等，该报告以 3.2.1 章节中扫描范围提到的 WASC Threat Classification 分类组织。图 7 为 Web 站点安全报告示例，所有安全问题按照严重等级分类，选择报告中的具体类型，可以得到更为详细的信息，如图 8 所示。 图 7 Web 站点应用安全报告示例 图 8 Web 站点应用安全报告详细信息 结构安全报告：列出了在扫描中发现的所有结构安全隐患，它们通常来自于第三方产品的错误配置或者缺陷，需要由系统管理员或网络管理员解决。 修复任务报告：该报告提供了针对每一隐患的修复方案。 法规遵从报告 包含了近 40 种法规和行业遵从，如著名的塞班斯（Sarbanes-Oxley Act）法案、银行 PCI 资料安全标准（Visa CISP）、Web 应用安全委员会风险分类（WASC Threat Classification）等等，如表 1 所示。 表 2－ ASE法规遵从报告标准 质量报告 断裂链接报告：该报告提供了在扫描中发现的断裂链接列表，帮助企业去除冗余信息，保证所有内容都可以被用户正确访问。 页面深度报告：该报告列出了从主页开始，需要访问到某一页面的点击数，帮助企业了解网站信息的可访问程度，如重要的信息是否需要用户多次点击才可访问。 慢速页面报告：该报告列出了用户下载速度很慢的文档页面，帮助企业发现需要长时间下载的文件，或者占用大量 Web 服务器空间的文件。 可访问性报告：扩大用户群，是企业 Web 应用的目标之一。根据统计，在某些地区，残疾人的比例接近 20％。而业界也出台了相应保障残疾人可以正常访问互联网应用的指南和法规，如 World Wide Web Consortium's Web Content Accessibility Guidelines（WCAG）、美国的 U.S. government's Section 508 法规、英国的 UK's Disability Discrimination Act 等。可访问性报告正是根据这些法规和指南，对企业的应用进行分析，得出改进意见，从而扩大企业 Web 应用的用户群。 隐私报告 Cookie 清单：该报告提供了在 Web 站点中发现的每一个 cookie 的内容和安全信息，如在哪些页面设置了 cookie、cookie 的安全等级如何等等，该报告可以帮助企业判断 cookie 的使用是否符合已有的隐私策略。 表单（Form）清单：该报告提供了 Web 站点中包含表单（Form）的页面清单，以及每个表单使用的提交方法等信息。 管理类报告 活动日志报告：该报告是由管理员创建的，主要用来统计 ASE 上的用户使用信息，如哪些用户正在使用系统、谁正在运行什么扫描、谁在制作 Dashboard 等等。 详细目录报告：该报告列出了扫描 Web 站点后的所有相关信息，如站点主机列表、所有页面列表、认证点列表、本地文件列表等等。 上面仅仅列举了 ASE 中提供的部分报告，在形成报告的同时，ASE 还可以将报告导出成 XML 文件、Excel 表格、PDF 文件或者 CSV 格式的文件，方便相关人员进一步讨论和分析。 除了上述丰富多彩的报告，ASE 还提供了仪表板分析（dashboard），它可以将数据再次整合，从更高层面分析 Web 站点的安全情况。如图 9 所示，从上到下、从左到右分别展现了 Web 站点漏洞严重等级历史、漏洞状态变更历史、按照报告包分类的漏洞严重等级、Web 站点漏洞按照 WASC 分类的比例。 图 9 ASE 中仪表板示例 3. 具备问题管理流程的应用安全平台 问题管理功能可以帮助企业更好的管理和跟踪 Web 应用中发现的漏洞，这当然可以通过和现有缺陷管理平台的集成来实现。而 ASE 则提供了内置的问题管理流程，你可以定义发现的安全漏洞哪些属于误报，哪些已经被解决，尽早归类，这样它们就可以不出现在后续的报告中；也可以让你把状态为“打开”（Open）的问题转换为“已修复”（Fixed）、“进行中”（In Progress）、“已传递”（Passed）甚至“骚扰状态”（Noise），这样就可以更好的让相关人员了解每一个问题的进展。 管理安全隐患问题，有如下好处： 减少骚扰，更专注于真正漏洞的解决 当分析已经扫描出的 Web 应用安全漏洞时，我们可以把那些不需要被解决的轻量级问题标示为“骚扰状态”或者“已传递”。“骚扰状态”的问题包括那些误报的漏洞；“已传递”的问题可以包含那些需要手工验证或再次审核的漏洞。一旦把问题归类为“骚扰状态”或“已传递”状态，就可以专注处于“打开”、“重新打开”和“进行中”状态的问题，这些状态的问题很有可能是影响应用质量和安全的重点。 以修复问题为目的来跟踪它们 安全漏洞问题管理可以确保每个被发现的隐患都能得到解决。这里所谓的解决，可以是真正的修复，也可以是在今后的版本中修复或者根本不用修复的“误报”。同时，根据这些状态得出的安全漏洞趋势曲线，也可以协助企业定位当前所处的开发水平和能力级别。 图 10 是 ASE 中漏洞问题管理的图示。 图 10 ASE 中内置问题管理功能 4. 集中控制、灵活配置的应用安全平台 在前面我们提到 ASE 的系统组件设计比较灵活，可以根据企业的需要进行架构搭建和系统配置。 在部署 ASE 时，企业需要的服务器数量、使用的配置，完全依赖于打算如何使用该平台。最优化的配置包含诸多因素，如用户数、站点规模、需要执行的任务种类以及需要生成的报告。虽然这些情况千差万别，但是有一些基本的配置方案可供参考。 单台服务器配置 最简单的配置就是将 ASE 所有的组件，包括数据库安装在一台服务器上，如图 11 所示。该配置适合于产品评估、小型企业或者工作组。 图 11 ASE 单台服务器配置 当应用较多，系统性能下降时，使用单台服务器模式将无法满足企业的需要，这时，多台服务器配置将是更好的选择。 分离部分代理的多台服务器配置 在这种配置中，可以将控制服务器、数据库服务器和部分代理服务（如负责处理导入任务的代理服务）安装在一台服务器上，其它的代理服务（如负责内容扫描、负责架构扫描的代理服务）安装在不同的服务器上，如图 12 所示。 图 12 分离部分代理的多台服务器配置 分离数据库的多台服务器配置 在这种配置中，可以将控制服务器、部分代理服务安装在一台服务器上，数据库和其它的代理服务，安装在不同的服务器上，如图 13 所示。 将控制服务器和数据库分离，可以大大提高系统的性能，因为这样可以避免在一台服务器上，执行扫描任务和存储数据同时进行。 图 13 分离数据库的多台服务器配置 当安装和配置应用时，除了多台服务器的配置之外，还可以灵活的选择将多个控制服务器或代理的实例安装在一台机器上。 控制服务器的多实例配置 在有些时候，可能需要安装多个控制服务器在一台机器上。比如，如果企业中有多个部门，每个部门需要有自己的控制服务器来管理不同的虚拟目录，同时能够访问自己部门的独立数据库。见图 14。 图 14 控制服务器的多实例配置 多控制服务器还可以应用到如下的场景中：当需要建立一套验证环境而又不希望影响到现有的环境；当需要使用一部分控制服务器来扫描企业的外网（Internet）应用，同时还需要一部分控制服务器扫描企业的内网（Intranet）应用。 代理服务的多实例配置 在一台机器上安装多个代理服务的实例，可以同时运行多个不同的扫描任务，每个扫描任务访问不同的数据库。当一个控制服务器上没有扫描任务需要执行，而另一台控制服务器上有多个扫描任务时，多实例的代理服务可以继续执行，大大减少了单实例时，代理服务器的无任务时间。 图 15 代理服务的多实例配置 回页首 总结 从前面的介绍可以看出，企业级应用安全解决方案，已经不是对单一 Web 应用进行扫描、分析、修复的简单过程；而是在此基础之上，从更高的战略层面管理企业中的应用安全，让尽可能多的人员方便的参与到应用安全的建设中，用尽可能周到的流程和权限机制使应用安全的管理更为高效，让尽可能灵活的产品配置使企业利用现有资源发挥最大的效益。 本文的第二部分，“企业级 Web 应用安全解决方案实例”正是基于前面介绍的 IBM Rational ASE 平台，是本平台在企业中的具体应用。