1、目录1 金融业信息安全的现状 .52 银行业源代码检测的相关标准和要求 .72.1 信息安全等级保护基本要求 .72.2 信息安全管理体系要求（IDT ISO/IEC27001：2005） .72.3 支付卡行业数据库安全标准（PCI DSS） 82.4 网上银行系统信息安全通用规范 .82.5 电子银行业务管理办法及电子银行安全评估指引 .83 中国 XXXX 银行的软件安全现状 94 软件源代码安全扫描、审计和管理方案 .104.1 解决方案组成 .114.2 FORTIFY SCA 源代码安全测试方法 124.3 输出结果 .145 实施建议 .155.1 方案概要 .165.2 方案目
2、的 .165.3 使用模式 .165.4 产品配置建议 .176 FORTIFY SOFTWARE 应用软件安全方案给 XXXX 银行带来的价值 177 FORTIFY 案例及业内位置 187.1 公司产品背景 .187.2 部分中国客户名单 .197.3 GARTNER 权威机构最新排名 .198 附件一：OWASP 应用安全 TOP 10 安全漏洞及控制措施示例 208.1 应用开发弱点的原始清单 .208.2 跨站脚本攻击(CROSS SITE SCRIPTING - XSS) 228.2.1 描述 .228.2.2 控制措施 .238.3 注入缺陷 .238.3.1 描述 .238.3
3、.1.1 SQL 注入攻击 .248.3.2 控制措施 .258.4 恶意文件执行 .278.4.1 描述 .278.4.2 控制措施 .298.5 直接对象引用 .298.5.1 描述 .298.5.2 控制措施 .308.6 跨站请求伪造（CSRF） .308.6.1 描述 .308.6.1.1 CSRF 攻击 .328.6.2 控制措施 .338.7 错误处理不当 .338.7.1 描述 .338.7.2 控制措施 .348.8 失效的账户和线程管理类的威胁 .358.8.1 描述 .358.8.2 控制措施 .358.8.2.1 密码存储 .358.8.2.2 保护传输凭证 .368.
4、8.2.3 保护线程 IDs 368.8.2.4 保护帐号列表 .378.8.2.5 管理程序组件的信任关系 .378.9 加密存储不安全 .378.9.1 描述 .378.9.2 确认存在加密存储不安全脆弱性 .388.9.3 控制措施 .388.10 通信不安全 .388.10.1 描述 .388.10.2 控制措施 .398.11 无法限制 URL 访问 .398.11.1 描述 .398.11.2 控制措施 .401 金融业信息安全的现状从光大证券“乌龙指”到财付通多起账户被盗事件，互联网信息系统安全成为社会关注的重点。作为我国信息化前沿的核心行业，银行业的信息安全形势和自主可控体系一
5、直是行业建设的重点。保障金融信息安全也更符合十八届三中全会决定 “加强金融基础设施建设，保障金融市场安全高效运行和整体稳定”要求。因此建立银行业自主可控信息技术创新战略联盟机制，推动落实信息科技外包风险联合监督平台和外包合作组织机制，并进一步加强统筹和引导，着力解决一些关乎全局、影响长远的问题提上了更好的议程。“要牢牢守住信息安全底线。 ”中国银监会副主席郭利根在会议上强调，银行业信息科技工作要牢牢守住信息安全底线，切实开展科技顶层设计，深入落实“创新驱动”发展战略，深化银行科技工作体制机制改革,全面激发自主创新活力，以科技创新推动银行业发展转型，以科技引领提升银行业核心竞争力，不断增强风险抵
6、御能力。确保计算机系统和应用免受侵入和破坏是管理商业风险最为重要的一部分,每年企业都花了数百万美元的成本在计算机软件,硬件和服务方面去保护他们的IT 系统 ,数据免受诸如病毒. worms, ,黑客攻击，我们期望花更多的预算去减轻我们商业应用系统的信息安全，但是结果并不是我们想象的那样，现目前我们的信息系统仍然处在不安全的境地，据 IDC 的统计，至少有 75%的企业发现他们的系统被黑客成功地攻击过。我们已经建立了非常完善的认证系统、网络安全系统、入侵检测的防范措施，为什么我们的系统还是处在不安全的境地呢？通过全球的一些信息安全专家的调查和分析，他们得出这样一个结论：目前我们信息安全的主要问题
7、：是应用软件安全问题，而不是我们通常所认为的网络问题，操作系统问题.。这下面是来自 Gartner Group 和 NIST 的分析报告。“Over 75% of security vulnerabilities exist at the application layer, not the network layer. Its not just operating systems or web browsers, but all types of applications - particularly applications that automate key business proce
8、sses.”-Gartner Group 2008对于应用安全性的检测目前大多数是通过测试的方式来实现。测试大体上分为黑盒测试和白盒测试两种。黑盒测试一般使用的是渗透的方法，这种方法仍然带有明显的黑盒测试本身的不足，需要大量的测试用例来进行覆盖，且测试完成后仍无法保证软件是否仍然存在风险。现在白盒测试中源代码扫描越来越成为一种流行的技术，使用源代码扫描产品对软件进行代码扫描，一方面可以找出潜在的风险，从内对软件进行检测，提高代码的安全性，另一方面也可以进一步提高代码的质量。黑盒的渗透测试和白盒的源代码扫描内外结合，可以使得软件的安全性得到很大程度的提高。因此，应用软件的自身的安全问题是我们信息
9、安全领域最为关心的问题，也是我们面临的一个新的领域，需要我们所有的在应用软件开发和管理的各个层面的成员共同的努力来完成。2 银行业源代码检测的相关标准和要求2.1 信息安全等级保护基本要求根据基本要求中关于外包软件开发的相关要求，一级要求开始就对外36%41%1% 2%2%0% 3%15%Encryption ModuleNetwork Protocol StackOtherCommunication ProtocolHardwareOperating SystemNon-Server ApplicationsServer Applications92% of reported vulnera
10、bilities are in applications, not networksSource: NIST包开发软件在上线前进行恶意代码检测， “应在软件安装之前检测软件包中可能存在的恶意代码” 。在测试验收中，提出了对系统进行安全性测试， “应对系统进行安全性测试验收” 。在二级要求中，增加了对源代码进行后门检查的要求，“应要求开发单位提供软件源代码，并审查软件中可能存在的后门” 。三级要求中明确指出要求由第三方测试单位实施系统安全性测试， “应委托公正的第三方测试单位对系统进行安全性测试，并出具安全性测试报告” 。四级要求中增加了对源代码隐蔽信道的安全检查要求，从基本要求关于系统安全性测
11、试要求的变化可以看出，系统安全性测试强度不断提高，在四级要求中增加了对“隐蔽信道”的安全检查，测试机构从无要求转向了三级要求中明确规定的第三方测试单位。一级要求中的恶意代码检测和安全性测试，未明确要求进行源代码层面的安全测试， 基本要求要求在测试验收时进行必要的软件安全性测试，代码审查可以作为软件安全性测试一项其重要手段，但未进行明确的规定。在二级要求中增加了对源代码进行后门检查及四级要求中对源代码进行隐蔽信道检查，提供了源代码检测的必要依据。2.2 信息安全管理体系要求（IDT ISO/IEC27001：2005 ）根据信息安全管理系统要求中控制目标“防范恶意代码和移动代码” ，“应用中正确
12、处理” ， “技术脆弱性管理”的要求，应用系统必须以相应的控制措施提供相应的功能。为验证安全功能的实现，在 IT 审计工程中，必然需要相应的测试结论提供相应的支持。其中“防范恶意代码和移动代码” ， “应用中正确处理” ， “技术脆弱性管理”等要求均可以利用代码审查进行控制目标的验证。2.3 支付卡行业数据库安全标准（PCI DSS）PCI DSS 中 6.3.7 “在发布生产以前检查自定义代码，以识别所有潜在的编码漏洞” ，及 6.6“对于面向公众的 Web 应用程序，经常解决新的威胁和漏洞，并确保保护这些应用程序不受到以下任一方法的攻击” ，此项要求中明确提出了由独立于开发团队的内部组织或
13、第三方专业机构进行代码安全审查。对于银行业及金融业来说，此项业务需求将比较大。2.4 网上银行系统信息安全通用规范网上银行系统信息安全通用规范（试行）中 6.1.1.1 明确要求由外包方开发的客户端程序要进行代码安全测试并须通过第三方中立测试机构的安全检测，6.1.4.3 中 WEB 应用安全对编码规范约束、防止 SQL 注入攻击、防止跨站脚本攻击等对软件安全及代码安全做出了明确要求，而且指定了要求第三方机构出具相应的测评报告。2.5 电子银行业务管理办法及电子银行安全评估指引电子银行业务管理办法对电子银行系统的安全性进行了规范，指出在申请电子银行业务时需要提交电子银行安全性评估报告。目前电子
14、银行安全评估指引是电子银行安全性评估的准则，其第三十一条明确规定电子银行系统的安全性评估须包括应用系统安全性评估内容，但未对应用系统安全性评估方法进行明确规范，鉴于已出台的网上银行系统信息安全通用规范（试行） ，可以在其测试过程中，增加代码审查相关测评方法。通过以上政策及标准的调研发现，软件安全在等级保护、上市公司及金融银行业均有明确的要求，但鉴于不同组织机构对信息安全的接受程度、财务状况及相关业务审计要求来看，在金融银行业及上市公司推广该业务才是唯一的出路，但市场总体来说未必很大。3 中国 XXXX 银行的软件安全现状中国 XXXX 银行是目前中国优秀的银行之一，公司目前的应用软件开发主要采
15、取软件外包和自主研发相结合的模式，对于中国 XXXX 银行来讲，应用软件自身的安全问题，也是一个几乎全新的领域，但是他们已经意识到这是他们下一阶段为确保信息安全必须要做的一个非常重要的事情，在我们与他们前期的交流中我们了解到目前他们在实现开发应用安全软件方面还存在如下一些问题：1、 外包团队和公司的研发团队对于开发安全的应用软件的意识不浓和知识不足。许多已经被 CWE、OWASP、ISO17799、 PCI 等信息安全组织标识为严重软件安全漏洞的问题了解不足，或者了解深度不够，从而造成他们在编码的时候没有考虑到部分软件安全漏洞或者在安全漏洞的预防方面不够彻底和充分，因此在他们的应用系统中存在着
16、许多诸如 SQL-injection, Cross-site-Script 的软件安全漏洞。2、 没有完善的应用软件安全的审计策略和措施。由于缺少应用软件安全保护方面的知识，因此目前对于外包团队的项目进行软件安全审计的时候不知道在在软件的安全方面具体要审核那些内容，以及如何去预防这些漏洞，现目前也没有借助一些自动化的工具，因此对应用软件的原代码审计只能采用人工的方式，显得费时费力，并且效率低下，很多漏洞都未能检查到，迫切需要一种新的安全审计策略和措施来加强软件安全的审计问题。3、 没有应用安全信息的管理平台没有一个集中的应用安全信息管理平台供开发人员、审计人员和管理层交流，不便于内部对与软件项
17、目的安全风险进行收集、处理、分析和预测和评估。4、 针对银监会和人民银行等监管机构对于业务系统安全、源代码检查的合规管理要求准备不足，控制措施缺失。4 软件源代码安全扫描、审计和管理方案Fortify SCA（Source Code Analyzer）是一个静态的、白盒的软件源代码安全扫描工具。其扫描结果不但能够定位造成漏洞的代码所在行，而且能够提供详细的安全漏洞的信息、相关的安全知识的说明、以及修复意见。它能够支持多达 21 种的常见编程语言，如 ASP.NET、 C/C+、 C#、 Java、 JSP、 XML、VB.NET、ASP、PHP、Python、 Flex、 ABAP、 VB、V
18、BScript 等语言，支持 Windows、 Linux 、HP Unix、 Solaris，AIX 的操作系统平台和其上面的代码。SCA 在发现和分析漏洞方面是全面的，是业界最完整的静态代码分析器。SCA 的分析引擎和已获得专利的 X-Tier 数据流分析器（专利编号#7207065 ）在一个其它技术无法到达的深度对问题进行广泛检测。SCA 的分析引擎以最大和最全面的安全编码规则为基础，该规则中的漏洞类别超过 600 种，并且Fortify 的安全专家们还在不断的更新这些规则。SCA 在提供准确的结果方面相当的优异。由于其成熟的引擎技术和精确的安全编码规则，故其以非常低的误报率对问题进行排
19、名和分类。安全编码规则可以自动更新到先进的、切合时宜的能准确地识别漏洞的安全专业知识。另外，没有一个应用软件会和其它软件具有一模一样的风险特征，它们也不可能以同样的方式建立，因此，SCA 在包含的基本特征的基础上，进一步调用源代码分析器分析那些特殊的应用、组件或 Web 服务。SCA 已建得可以适应你的组织的环境。它的 规模可以从每天的日常编译到全面的审计数百万行的代码，同时它还支持一系列语言、平台、编译环境和集成开发环境（IDE） 。由于目标不同可由个人或团体来调用不同的分析标准。由于应用程序需要独特的规则，SCA 提供了一个方便易用的 Rules Builder，用户可以自定义分析。SCA
20、 提供了巨大的灵活性，以满足任何额外的要求。4.1 解决方案组成Fortify Source Code Analysis suite（SCA）包含： A. Fortify Source Code Analysis Engine（ 源 代 码 分 析 引 擎 ） 采 用 数据流分析引擎，语义分析引擎，结构分析引擎，控制流分析引擎，配置分析引擎和特有的 X-Tier 跟踪器从不同的方面查看代码的安全漏洞，最大化降低代码安全风险。B. Fortify Secure Code rules： Fortify （ 软 件 安 全 代 码 规 则 集 ）采 用 国际公认的安全漏洞规则和众多软件安全专家的建议
21、，辅助软件开发人员、安全人员和管理人员快速掌握软件安全知识、识别软件安全漏洞和修 复 软 件 安 全 漏 洞 。 其 规 则 的 分 类 和 定 义 被 众 多 国 际 权 威 机 构 采 用 ， 包 括美 国 国 土 安 全 （ CWE） 标 准 、 OWASP，PCI 等。C. Fortify Audit Workbench （ 安 全 审 计 工 作 台 ）辅 助 开 发 人 员 、 安 全 审 计 人 员 对 Fortify Source Code Analysis Engines（ 源 代 码 分 析 引 擎 ） 扫 描 结 果 进 行 快 速 分 析 、 查 找 、 定 位 和 区
22、 分软 件 安 全 问 题 严 重 级 别 。 D. Fortify Rules Editor （安全规则构建器）提供自定义软件安全代码规则功能，满足特定项目环境和企业软件安全的需要。E. Fortify SCA plug in （Fortify SCA IDE 集成开发插件）Eclipse, Visual Studio, RAD 集成开发环境中的插件，便于开发者在编写代码过程中可以直接使用工具扫描代码，立刻识别代码安全漏洞，并立即根据建议修复，消除安全缺陷在最初的编码阶段，及早发现安全问题，降低安全问题的查找和修复的成本。F. Fortify Software Security Center
23、（Fortify 软件安全管理中心）基于 WEB 企业用户接口的软件安全信息存储分析评估和报告的软件安全管理平台.主要功能是定义和监视软件安全策略、跟踪和报告软件安全趋势、跨多个应用管理软件安全风险。公司的管理层可以通过对目前商业应用系统的分析而得出应用软件的安全策略，安全的策略使用管理平台进行管理和跟踪，安全的审计人员在贯彻公司的安全策略的同时，通过配置或者自定义软件安全规则来达到策略的要求，并为开发团队或者外包团队员提供安全代码规范，当开发人员在开发代码时，使用源代码扫描工具自动识别安全漏洞并修复它，并向审计人员提供已经开发完的源代码，审计人员审核代码是否合乎公司的安全代码规范和安全策略，
24、并上传报告给公司的管理层。4.2 Fortify SCA 源代码安全测试方法通过白盒（代码审计）的方式检查应用系统的安全性，白盒测试所采用的方法是工具审查+人工确认+人工抽取代码检查，依照 OWASP 2013 TOP 10 所披露的脆弱性，根据业务流来检查目标系统的脆弱性、缺陷以及结构上的问题。简单介绍代码审计的流程。Fortify Source Code Analysis Suite 是目前在全球使用最为广泛的软件源代码安全扫描，分析和软件安全风险管理软件。该软件多次荣获全球著名的软件安全大奖，包括 InforWord, Jolt，SC Magazine.目前众多世界级的软件开发企业都在使
25、用该软件方案在他们的开发团队中加速查找软件安全漏洞的效率，监视和管理软件安全的风险。1) 首先使用 Fortify 工具完成对目标程序的初步审查。如下图所示。2) 对于中大型程序，Fortify 一般会检测出成千上万的安全风险点。在这么多安全风险点中，不乏一些重复或者是误报。这就需要技术人员，使用测试工具和自身的安全经验去一一验证确认这些漏洞是否真实存在。如在 WEB 应用程序中，检测出 XSS 漏洞，那么技术人员就需要在实际的搭建环境中，检测这个 XSS 漏洞是否存在。3) 在技术人员人工实际检测漏洞存在后，就会定位到此安全风险点对应的程序源代码。如下图，使用 Fortify 定位程序风险点
26、位置。4.3 输出结果源代码安全审计的交付物为审计报告，其内容包括：1) 所使用的开发技术和编程语言中常见的错误。2) 每一个已识别漏洞的报告，包括漏洞的概述、影响和严重性以及再现该漏洞的步骤和可用于修复该漏洞缺陷的补救措施建议。例如，下表为反射型跨站漏洞的一个漏洞报告分析实例。Admin_Pl.asp, 35 行 跨站脚本攻击：反射型(Cross-Site Scripting: Reflective)危险等级： 中目录位置： Admin/admin_pl.asp摘要: 在 admin_pl.asp 文件 35 行，存在未经验证的输入数据，这可能会导致浏览器执行恶意代码。污染数据点: Admi
27、n_Pl.asp:35 行 读取 requestkeyword()34 未审的评论35 关健字：“36 漏洞引爆点: Admin_Pl.asp:35 行 执行 write(0)34 未审的评论35 关健字：“36 3) 详细说明被审计代码的总体情况、审计发现的问题、进行追加审计的建议，以及针对已确定漏洞进行补救的建议。5 实施建议根据目前的软件项目开发和软件测试状况，浩达恒业相信，Fortify 完整的安全测试解决方案和多年的部署实施经验，一定能帮助中国 XXXX 银行解决软件安全的问题。根据多年的银行客户实施经验，我们推荐中国 XXXX 银行采用以下实施方案：5.1 方案概要(1) 使用 F
28、ortify SCA+SSC 建立软件源代码安全审计模式(2) 产品部署及使用角色设置方案 5.2 方案目的本方案通过建立一套完整的安全测试审计制度，减少由不规范、不安全的编码而产生的安全性漏洞，来真正地帮助中国 XXXX 银行提高其 IT 应用系统的质量和安全性，提高源代码安全开发，测试及安全管理水平。5.3 使用模式根据 Fortify 对中国 XXXX 银行目前软件开发项目流程的了解，结合Fortify 多年来为全球客户成功实施部署的经验，Fortify 建议中国 XXXX 银行实施“Gate ”模式的审计方式，即在验收测试阶段引入安全测试，大部分 Fortify 的中国客户最初都是使用
29、这种模式。具体如下：需求分析 功能/验收 测试 QA/性能测试 发布架构设计 编码SCA 源代码扫描图 1：Fortify SCA 审计模式示意图“Gate”审计模式说明：(1) 软件安全测试或审计人员通过代码版本控制器，把开发人员提交的项目代码的阶段版本，用 Fortify SCA 进行扫描分析，并给予审计。(2) 审计人员将项目的审计结果报告于开发人员（或外包商）对其漏洞进行修复。(3) 审计通过的项目进入下一阶段的其它测试或者正常阶段发布。(4) 审计人员将每一次扫描审计的结果发布于 Fortify SSC(Software Security Center)中，便于管理人员查看漏洞，了解
30、项目漏洞程度，安全趋势等综合状况信息。同时，结合 Fortify SSC 的 Collaboration Module 功能，开发人员（外包商） ，审计人员，安全管理人员可以通过 Web 方式查看到 SCA 的扫描结果以及审计状态等详细信息，方便对安全漏洞的查看，交流，沟通工作以及代码的修改。5.4 产品配置建议SKU# Product Product Description on price listQuantityTF307AAE FSCA B2O SE SW E-LTUFSCA B2O SE SW E-LTU Fortify Static Code Analyzer Build To O
31、rder Deployment Plan Starter Edition Software E-LTU1 WXU 5*9 Support for TF307AA 5*9 Support 1 6 Fortify Software 应用软件安全方案给XXXX 银行带来的价值1、 轻松应对监管机构的合规需求，提高源代码审计效率，降低应用系统安全风险。2、 丰富而全面软件安全代码规范及其文档资料弥补中国 XXXX 银行开发人员和管理人员应用软件安全知识不足，让大家尽快了解各种软件安全漏洞的成因和修复方法。3、 使用 Fortify SCA 大大节约了开发人员和审计人员在识别软件漏洞和修复安全漏洞的时间
32、。4、 对于软件外包的项目，能快速识别项目风险，防止外包团队成员有意或者无意而遗留在软件项目中的安全隐患，避免以后软件上线后造成重大的经济和其他方面损失。5、 通过使用 Fortify 的工具可以帮助中国 XXXX 银行研发中心建立规范的代码安全审计流程，并使在项目验收过程中引入软件安全验收环节变为可行。6、 通过 Fortify SSC(Software Security Center)的使用和软件安全测试规范的制定，便于 XXXX 银行针对不同的软件项目制定软件安全的策略和安全的代码规范，并且能在软件开发的生命周期中去贯彻和实施这些规范和策略，并且跟踪和管理他们。7 Fortify 案例及
33、业内位置7.1 公司产品背景Fortify Software 2003 年由 Kleiner Perkin Claufield& Byers 风险基金投资成立，总部设在美国加州硅谷。Fortify Software 是世界上第一个提出软件安全新理念的公司，并于 2004 年推出业界第一款产品。公司 CTO 兼创始人 Mr Roger Thornton 是世界软件安全这一新领域的主要缔造者， 公司另一创始人Dr Brian Chess 是世界级安全专家。Fortify Software 的产品主要为软件源代码扫描器，软件应用监控， 渗透测试覆盖率检测等。公司拥有 150 多项专利，居行业之首。目
34、前全球已有 600 家客户，其中银行，保险，证券占一半以上。全球 8 大银行如汇丰，花旗，WellsFargo， Morgan 已全部采用 Fortify Software 的解决方案。其他领域的客户为电子商务类的 eBay, Google, 软件厂商 Oracle，Microsoft 和 EMC 等以及政府部门。 2008 年 4 月 Fortify Software 在中国设立了北京代表处，并对产品的关键内容进行了汉化, 2010年 Fortify 被 HP 收购，统一纳入惠普企业安全产品部 ESP，成为其重要组成部分。7.2 部分国际客户名单国内的主要客户：7.3 Gartner 权威机
35、构最新排名Fortify 解决方案一直在 AST(应用安全测试领域)排名全球第一，如下图是2014 年最新的排名，依然遥遥领先7.4 Fortify SCA4.1 关键新功能摘要 目前 SSC4.1 可以正确的和 HP ALM 解决方案集成，原来 4.0 存在的问题已经被修复。 重新在 4.1 版本中增加了对 IBM AIX 操作系统的支持，在 4.0 版本是不支持 IBM AIX 操作系统的 增加了对 Java 8 的支持 SSC 4.1 中对 BIRT 报表系统的支持得到了增强，原来 SSC4.0 中仅支持BIRT 2.6.2，现在可以支持到 BIRT4.3.1。 （注：BIRT (Bus
36、iness Intelligence and Reporting Tools), 是为 Web 应用程序开发的基于 Eclipse 的开源报表系统） 在报告模板中增加了 OWASP TOP 10 2013 的支持，之前的版本仅支持OWASP2010 增加了对 PCI3.0 的支持，原来的版本只支持 PCI2.0(注:PCI 3.0 是目前支付卡行业数据安全标准最新的版本，所有银行、第三方支付，以及涉及到银行卡支付的企业都要遵循的国际标准) 在 SSC4.1 中为了简化客户自定义报表的复杂度，增加了可以重用的报表库，方便客户进行报表的自定义。 对 IE8 的支持，修正了 SSC4.0 不支持 I
37、E8 的错误 SCA4.1 增加了对微软 Visual Studio 2013 的支持 增加了对 Windows 2012, Windows 8, and Windows 8.1.的支持 增加了对 Xcode 的支持(注：Xcode 是苹果公司开发的编程软件，是开发人员建立 OS X 和 iOS 应用程序的最快捷方式，Xcode 前身是继承自NeXT 的 Project Builder。The Xcode suite 包含有 GNU Compiler Collection 自由软件 （GCC、 apple-darwin9-gcc-4.0.1 以及 apple-darwin9-gcc-4.2.1
38、, 默认的是第一个） ，并支持 C 语言、C+、Fortran、Objective-C、Objective-C+、Java、AppleScript、Python 以及 Ruby，还提供 Cocoa、Carbon 以及 Java 等编程模式。协力厂商更提供了 GNU Pascal，Free Pascal, Ada, C#, Perl, Haskell 和 D 语言。Xcode 套件使用 GDB 作为其后台调试工具。)8 附件一：OWASP 应用安全 Top 10 安全漏洞及控制措施示例本指南引用了 OWASP(Opening Web Application Security Project)To
39、p 10 应用开发弱点清单，并列出相应的控制措施。8.1 应用开发弱点的原始清单应用系统弱点 描述A1 - Cross Site Scripting (XSS)XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victims browser which can hi
40、jack user sessions, deface web sites, possibly introduce worms, etc. A2 - Injection FlawsInjection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker?s hostile data tricks t
41、he interpreter into executing unintended commands or changing data. A3 - Malicious File Execution CodeCode vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks
42、affect PHP, XML and any framework which accepts filenames or files from users. A4 - Insecure Direct Object Reference A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parame
43、ter. Attackers can manipulate those references to access other objects without authorization. A5 - Cross Site Request Forgery (CSRF)A CSRF attack forces a logged-on victim?s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim?s browser to perform
44、 a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. A6 - Information Leakage and Improper Error HandlingApplications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety o
45、f application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks. A7 - Broken Authentication and Session ManagementAccount credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to as
46、sume other users? identities. A8 - Insecure Cryptographic StorageWeb applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud. A9 - Insecure Communications Appli
47、cations frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. A10 - Failure to Restrict URL Access Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this
48、weakness to access and perform unauthorized operations by accessing those URLs directly. 8.2 跨站脚本攻击(Cross Site Scripting - XSS)8.2.1 描述在允许代码注入的 Web 应用程序中常常可以发现 XSS 脆弱性。利用这种弱点的脚本可能来自服务器，但它们并不在那里执行；相反，它们在客户端工作站上执行。有两种基本的 XSS 脆弱性：反射式和存储式的 XSS 脆弱性。反射式脆弱性是最常见的形式。当用户可以向一个文本框中输入语法内容，然后在用户的显示器上显示出来时，往往存在这种脆
49、弱性。当一名攻击者用这种脆弱性定位一个页面时，他只需简单地在框中输入脚本。当页面再次显示输入的文本时，脚本就开始执行。许多时候，必须使用社会工程使用户访问一个专门制作的 URL 来发动攻击。这样做可能导致在页面中插入攻击者的脚本（Jeremiah Grossman ， 跨站脚本蠕虫和病毒 ，2006 年4 月） 。存储脆弱性就像它的名称指出的那样。攻击者向其他用户经常访问的网站，或网站的一个区域提交利用 XSS 弱点的代码。这类例子包括社交网络网站和读者对所发表内容的评论。当受害者的浏览器打开被感染的网页时，脚本不需要用户干预即可自动执行。这是因为存储的恶意脚本被浏览器看作是来自一个可信网站/服务器的脚本。下面是一个非常简单的存储脚本攻击实例。最初，脚本可能被插入到一个表单框中，并最终进入大量用户使用的论坛或其它服务中。例如，在一个在线论坛中发贴时，攻击者可能会输入以下脚本：alert(Hello World)当一个没有疑心的用户打开论坛中的贴子时，这段脚本就会在用户的工作站上运行。其显示结果是一段无害的文本，但如果脚本中包括以下代码，情况就会有所不同：1. 显示许可出错信息2. 提示用户输入密码 3. 将密码通过电子邮件发送到攻击者的服务器 一旦攻击者成功利用
