代码安全性检测指导规范1109.docx

1、代码安全性检测指导规范1109应用安全性测试指导规范（草稿）1. 进行应用安全性测试的场景安全性测试的目的是验证集成在软件内的保护机制是否能够在实际环境中保护系统的安全性。从严格意义上，应用系统的安全性将涉及到应用的设计、开发和部署这三个主要环节，因而理想化的应用安全性测试应是与整个软件开发过程紧密集成的，即在软件设计、开发、测试和部署的过程中动态检测程序代码的安全性，并在应用最终部署之后进行全面的安全性测评。只有将应用和代码安全的管理融入到应用开发、部署、运维的各环节中，才能确保应用系统的安全性。在应用系统上线并进入运维阶段之后，也需要在维护性开发过程中进行类似的代码安全性测试，并在日常的应

2、用维护过程中动态进行应用整体安全性的评测。代码安全性作为应用安全性中的一个核心的内容，是保障代码开发安全性的一个重要的举措，在开发活动结束的节点上应重点加强。而应用开发完毕后的部署和运维环节中，还将涉及到应用系统整体安全性评估的其他内容（包括网络安全、操作安全、权限安全、数据安全等）。应用安全性测试的相关文档应纳入项目管理和运维管理的文档管理体系。1.1 初期的应用安全性测试场景在传统的软件开发管理模式中引入应用安全测试将需要一个逐步的过程，在初期建议在如下的应用场景下，对目标应用系统的安全性进行测试：应用开发阶段新应用软件开发完毕，通过开发团队内部测试，即将交付验收测试之前，应组织对应用代码

3、进行安全性测试。新应用软件部署完毕之后，应组织对目标应用系统进行整体的安全性测评。应用维护阶段应用软件在维护性开发完毕，通过维护团队内部测试，即将交付验收测试之前，应组织对维护开发所涉及部分的代码安全性进行测试。应用软件维护性开发部分部署或系统软硬件架构重大变更实施完毕之后，应组织对目标应用系统受影响部分进行安全性补充测评。1.2 目标的应用安全性测试相关场景而从更完整意义上的应用系统整个生命周期各阶段中，需要进行的应用系统安全性测试、评估的工作可大致规划如下（供参考）：应用设计阶段应用项目立项时，应明确系统的安全目标和安全功能需求，并通过用户方的（建设方案）评审。应用软件设计方案中应增加系统

4、安全性设计部分，细化目标系统的安全目标和安全功能，并通过用户方组织的（实施方案）评审。应用软件测试方案中应增加系统安全性测试内容，提供细化的安全性测试方案，并通过用户方组织的（测试方案）评审。应用开发阶段在应用代码开发的自测和集成测试阶段，利用IDE整合的代码分析工具，对开发的代码安全性进行动态评估。（项目团队自评）新应用软件开发完毕，通过开发团队内部测试，即将交付验收测试之前，应组织对应用代码进行安全性测试。（第三方代码安全测评）应用上线阶段新应用软件部署完毕之后，应组织对目标应用系统进行整体的安全性测评（根据安全测试方案）及整改。（第三方应用安全整体测评）应用维护阶段应用软件在维护性开发完

5、毕，通过维护团队内部测试，即将交付验收测试之前，应组织对维护开发所涉及部分的代码安全性进行测试。应用软件维护性开发部分部署或系统软硬件架构重大变更实施完毕之后，应组织对目标应用系统受影响部分进行安全性补充测评。应用日常维护过程中，应根据应用安全等级，定期进行应用安全性评测和改进。（例行应用安全测评）2. 应用安全性测试的范围与内容应用安全性测试的范围与内容，应包括如下几个方面：测评项测评内容部署与基础结构网络是否提供了安全的通信部署拓扑结构是否包括内部的防火墙部署拓扑结构中是否包括远程应用程序服务器基础结构安全性需求的限制是什么目标环境支持怎样的信任级别输入/输出和编码如何验证输入是否清楚入口

6、点是否清楚信任边界是否验证Web页输入是否对传递到组件或Web服务的参数进行验证是否验证从数据库中检索的数据是否将方法集中起来是否依赖客户端的验证应用程序是否易受SQL注入攻击应用程序是否易受XSS攻击应用程序是否易受OS注入攻击应用程序是否易受Cookie定制/隐藏文件操纵攻击如何处理输入输出信息是否涉及泄密数据编码处理过程是否存在安全漏洞身份验证是否区分公共访问和受限访问是否明确服务帐户要求如何验证调用者身份如何验证数据库的身份是否强制试用帐户管理措施访问授权如何向最终用户授权如何在数据库中授权应用程序如何将访问限定于系统级资源配置管理是否支持远程管理是否保证配置存储的安全是否隔离管理员特

7、权敏感数据是否存储机密信息如何存储敏感数据是否在网络中传递敏感数据是否记录敏感数据会话管理如何交换会话标识符是否限制会话生存期如何确保会话存储状态的安全加密为何使用特定的算法如何确保加密密钥的安全性参数操作是否验证所有的输入参数是否在参数过程中传递敏感数据是否为了安全问题而使用HTTP头数据异常管理是否使用结构化的异常处理是否向客户端公开了太多的信息审核和日志记录是否明确了要审核的活动是否考虑如何流动原始调用这身份源代码错误缓冲区溢出漏洞。字符串格式化漏洞。优先权提升漏洞。3. 应用安全性验收的流程与方法3.1 应用安全性验收的流程应用安全性验收的流程图如下：3.1.1 IT项目安全测评保护要

8、求管理（1）上海电信内部IT系统的分级安全保护要求的编制与复审规划处牵头，会同各应用域及信息中心、移动业务支撑中心共同编制上海电信内部IT系统的分级安全保护要求。规划处负责定期组织对编制的IT系统分级保护要求进行评估和复审，确保该要求能反映业务需求的变化，并适应于当前的内部IT基础架构现状。（2）上海电信内部IT系统安全保护评估指南的编制与复审规划处负责牵头并会同相关的安全测评服务商，根据IT系统分级保护要求细化并制定上海电信内部IT系统安全保护评估指南，作为各IT项目验收环节系统安全保护能力测评与验收的参考基准。规划处在IT系统分级保护要求变更后，应及时组织对IT系统安全保护评估指南文档做相

9、应调整与更新。3.1.2 IT项目安全测评管理（1）安全测评方案编制与评审在IT项目的实施方案编制阶段，由电信项目经理牵头，组织相关应用域、IT项目承建方、第三方安全测评服务商依据上海电信内部IT系统安全保护评估指南共同编制该IT项目的安全测评方案。项目安全测评方案编制完成后，应和项目实施方案一同进行实施方案的评审环节。（2）IT项目安全测评IT项目承建方在完成项目建设实施工作后，在正式提出项目验收请求之前，向第三方安全测评服务商申请进行项目安全测评。第三方安全测评服务商将按照评审通过的项目安全测评方案，组织现场安全测评，汇总测评结果并提出安全整改意见给IT项目承建方和电信项目经理。IT项目承

10、建方在接到项目安全整改意见后，应及时组织针对性的安全整改工作，并向第三方测评服务商申请整改复审。第三方测评服务商在收到整改复审申请后，针对整改意见进行复审测评，直至所有整改项均符合要求。全部测评项通过后，第三方测评服务机构出具项目安全测评报告，并汇总测评相关技术文档提交至电信项目经理。电信项目经理在收到项目安全测评报告后，组织常规的IT项目验收工作，并在项目验收时将安全测评相关文档并入项目技术文档保存。（3）IT项目的移交在IT项目建设完毕后的维护移交阶段，应同步将应用系统的安全要求和安全保护指南转换为相应的应用系统安全维护指南，作为应用维护阶段的安全维护基准。3.1.3 IT项目运维安全测评

11、管理（1）维护性开发的安全测评在维护性开发工作启动阶段应参照应用系统安全维护指南确定维护性开发相关部分的安全保护评估指南，并细化为对应的安全测试方案，作为维护性开发结束的安全评估的基准。维护性开发工作结束，由移动业务支撑中心牵头，组织相关应用域、维护服务提供商、第三方安全测评服务商共同完成维护性开发涉及部分系统的安全测评和整改，并作为维护性开发验收的必要条件之一。（2）日常维护安全测评移动业务支撑中心应根据应用系统安全维护指南，组织第三方安全测评服务商按照应用系统的分级安全保护要求进行定期的系统安全测评，并根据测评结果对IT基础架构、应用系统进行必要的安全改进。应用系统的日常安全维护文档也纳入

12、维护文档管理体系。3.2 应用安全性测试的方法3.2.1 测试方法概述应用安全性测试与验收的方法主要包括：静态的代码安全测试（白盒法）：主要通过对源代码进行安全扫描，根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对，从中找出代码中潜在的安全漏洞。该方法非常有用，可在编码阶段找出所有可能存在安全风险的代码，这样开发人员可以在早期解决潜在的安全问题。静态代码测试更适用于早期的代码开发阶段，而不是测试阶段。动态的渗透测试（黑盒法）：渗透测试也是常用的安全测试方法。是使用自动化工具或者人工的方法模拟黑客的输入，对应用系统进行攻击性测试，从中找出运行时刻所存在的安全漏洞。该测试方法的特

13、点是真实有效，一般找出来的问题都是正确的，也是较为严重的。但渗透测试一个致命的缺点是模拟的测试数据只能到达有限的测试点，覆盖率很低。程序数据扫描：通常是进行内存测试，内存测试可以发现许多诸如缓冲区溢出之类的漏洞，而这类漏洞使用除此之外的测试手段都难以发现。该测试方法主要用于确保有高安全性需求应用在运行过程中的数据安全性。数据扫描通畅需要专门的工具来进行验证。3.2.2 应用安全测试的成功要素成功的应用安全测试需要做好如下方面的充分准备： 充分了解软件安全漏洞：评估一个软件系统的安全程度，需要从设计、实现和部署三个环节同时着手。这一点可参考通用评估准则（Common Criteria）的软件系统

14、安全评估方法来理解：首先要确定软件产品对应的Protection Profile（PP,产品的安全特性模板），然后根据PP再提出具体的安全功能需求，最后确定安全对象以及是如何满足对应的安全功能需求的。因此，一个安全软件的三个环节，哪个出问题都不行，需要充分了解各环节的软件安全漏洞。安全性测试的评估：需要建立对测试后的安全性评估机制，一般可从如下两个方面进行评估：安全性缺陷数据评估：直接分析评估目标代码，如果发现软件的安全性缺陷和漏洞越多，可能遗留的缺陷也越多。进行这类评估时，必须建立基线数据作为参照，否则评估起来没有依据就无法得到正确的结论。采用漏洞植入法来进行评估：通过在目标代码中植入一些有

15、安全漏洞，然后测试可发现的植入漏洞，并以此来评估软件的安全性测试做得是否充分。采用安全测试技术和工具：可使用专业的具有特定功能的安全扫描软件来寻找潜在的漏洞，将已经发生的缺陷纳入缺陷库，然后通过自动化测试方法来使用自动化缺陷库进行轰炸测试。3.2.3 反向安全测试与正向安全测试（1）反向安全性测试过程大部分软件的安全测试都是依据缺陷空间反向设计原则来进行的，即事先检查哪些地方可能存在安全隐患，然后针对这些可能的隐患进行测试。因此，反向测试过程是从缺陷空间出发，建立缺陷威胁模型，通过威胁模型来寻找入侵点，对入侵点进行已知漏洞的扫描测试。其优点是可对已知的缺陷进行分析，避免软件里存在已知类型的缺陷

16、；缺点是对未知的攻击手段和方法通常会无能为力。反向安全性测试的常规过程将包括：建立缺陷威胁模型。建立缺陷威胁模型主要是从已知的安全漏洞入手，检查软件中是否存在已知的漏洞。建立威胁模型时，需要先确定软件牵涉到哪些专业领域，再根据各个专业领域所遇到的攻击手段来进行建模。寻找和扫描入侵点。检查威胁模型里的哪些缺陷可能在本软件中发生，再将可能发生的威胁纳入入侵点矩阵进行管理。如果有成熟的漏洞扫描工具，那么直接使用漏洞扫描工具进行扫描，然后将发现的可疑问题纳入入侵点矩阵进行管理。入侵矩阵的验证测试。创建好入侵矩阵后，就可以针对入侵矩阵的具体条目设计对应的测试用例，然后进行测试验证。（2）正向安全性测试过

17、程为了规避反向设计原则所带来的测试不完备性，需要一种正向的测试方法来对软件进行比较完备的测试，使测试过的软件能够预防未知的攻击手段和方法。正向安全性测试过程通常包括：先标识测试空间。对测试空间的所有的可变数据进行标识，由于进行安全性测试的代价高昂，其中要重点对外部输入层进行标识。例如，需求分析、概要设计、详细设计、编码这几个阶段都要对测试空间进行标识，并建立测试空间跟踪矩阵。精确定义设计空间。重点审查需求中对设计空间是否有明确定义，和需求牵涉到的数据是否都标识出了它的合法取值范围。在这个步骤中，最需要注意的是精确二字，要严格按照安全性原则来对设计空间做精确的定义。标识安全隐患。根据找出的测试空

18、间和设计空间以及它们之间的转换规则，标识出哪些测试空间和哪些转换规则可能存在安全隐患。例如,测试空间愈复杂，即测试空间划分越复杂或可变数据组合关系越多也越不安全。还有转换规则愈复杂，则出问题的可能性也愈大，这些都属于安全隐患。建立和验证入侵矩阵。安全隐患标识完成后，就可以根据标识出来的安全隐患建立入侵矩阵。列出潜在安全隐患，标识出存在潜在安全隐患的可变数据，和标识出安全隐患的等级。其中对于那些安全隐患等级高的可变数据，必须进行详尽的测试用例设计。（3）正向和反向测试的区别正向测试过程是以测试空间为依据寻找缺陷和漏洞，反向测试过程则是以已知的缺陷空间为依据去寻找软件中是否会发生同样的缺陷和漏洞，

19、两者各有其优缺点。反向测试过程主要的一个优点是成本较低，只要验证已知的可能发生的缺陷即可，但缺点是测试不完善，无法将测试空间覆盖完整，无法发现未知的攻击手段。正向测试过程的优点是测试比较充分，但工作量相对来说较大。因此，对安全性要求较低的软件，一般按反向测试过程来测试即可，对于安全性要求较高的软件，应以正向测试过程为主，反向测试过程为辅。3.2.5 软件生命周期中的应用安全保证机制*（这部分属于最终要建立的覆盖软件生命周期的安全保证机制，供参考）在保证应用安全的整个生命周期中，需要涉及多个基本任务，这些任务包括： 设置安全需求 (Set Security Requirements)：由安全专家

20、或相关人员指定在项目中哪些问题可以被定义为安全漏洞、每种安全漏洞对项目的影响程度。 配置 (Configure)：针对不同的项目，进行必要的配置以扫描应用。 扫描 (Scan)：扫描项目代码并返回结果。 优选 (Triage)：根据扫描的结果进行排选，发现影响最大、需要立即修复漏洞的过程。 解决 (Resolve/Remediate)：通过修改代码、增加安全函数、移出缺陷等方式修复发现的安全漏洞。 验证 (Verify)：重新扫描代码以保证安全漏洞已经被正确修复。 企业可以根据规模、人力等因素将这些任务和不同的角色相结合，因此在软件开发的生命周期中保证应用安全，就会产生如下三种部署模式。在具体

21、应用时，可根据各项目组的实际情况来灵活选择。（1）简易模式简易模式下，相关角色的职责分别为：管理人员或者安全专家：设置安全需求定义，同时建立验证标准；在项目过程中查看报告，获知安全相关的信息；研发人员：从源代码控制系统中检出代码进行开发；在任何时候都可以自行配置扫描工具进行扫描，并分析扫描结果；决定如何去修复，最后在修复完成后再次运行扫描，来验证是否修改正确，如果正确，则将代码检入到源代码控制系统，否则继续进行修改。这种模式的优点是易于实现，仅涉及两种角色，管理人员和开发人员。非常适合小规模的开发团队，以及需要进行审计的项目。同时，由于产生交互的环节少，而且由写代码的开发人员自己发现问题，可以

22、更有效的优选和解决安全漏洞。该模式的缺点是不适合大规模部署，增大了开发人员的工作量，对开发人员也提出了更高的要求，他们需要了解一定的安全知识。同时，很难将企业的流程和策略加到代码修复过程中。（2）分布模式该模式将质量管理人员和产品发布团队纳入到应用安全生命周期中。分布模式下，相关角色的职责分别为：管理人员或安全专家：设置安全需求定义；连接到源代码控制系统了解开发进度；审阅 QA 团队提供的评估数据或报告。QA 团队或产品发布团队：进行扫描配置，还可以选择将扫描工具和现有的 Build 系统集成，实现在构建过程中自动加入应用代码安全审计的目的；在设定的里程碑时间点，从源代码控制系统中同步代码并对

23、其进行安全扫描；将扫描完成的源数据（源数据包括扫描出来的漏洞信息和源代码的正确版本）发送给开发人员；并将扫描结果形成报告发送给管理团队。开发人员：对发送给自己的安全扫描结果进行优选；根据项目需要选择修复；重新测试以验证并将正确的代码检入到源代码控制系统。分布模式的优点是部署灵活，可以和 build 过程紧密结合，充分利用自动化的构建过程发现安全漏洞，提高了工作效率，而且 QA 和产品发布人员承担了一部分的安全诊断工作，减轻了开发人员工作量的同时，使更多的角色参与到应用安全的范畴中。另外，由 QA 团队集中产生安全评估报告，也能方便管理团队全面了解企业的应用安全现状。该模式适合中到大型企业以及希

24、望加入一定控制措施的应用。但是同样要求开发人员有较强的安全知识。（3）集中模式集中模式下，相关角色的职责分别为：管理人员或者安全专家：设置安全需求定义；连接到源代码控制系统了解开发进度；审阅安全分析团队或 QA 团队提供的评估数据或报告。安全分析团队或 QA 团队：配置扫描工具，并可以选择和企业的 build 系统集成；从源代码控制系统中获取最新的代码进行扫描；对扫描结果进行优选；将优选结果根据某种分类打包，提交到企业的缺陷跟踪系统中；从缺陷跟踪系统中获得漏洞修复的最新情况，形成应用安全报告提交给管理团队；开发人员：从缺陷跟踪系统中接受任务，修复代码；重新测试进行验证，并将正确结果检入到源代码

25、控制系统。集中模式和其它模式的区别主要是开发人员不需要承担多余的安全分析工作，只将注意力放在和修复其它缺陷一样进行代码修复，由安全分析团队或者 QA 团队集中承担安全诊断的工作。这种模式的好处是职责分明，能够和企业现有的系统，如 build 系统、缺陷跟踪系统集成，很好的遵循了企业固有工作模式。而且将安全分析工作集中起来，便于企业集中培训和指导安全人员，使得每个角色在参与到应用安全的同时，不用承担更多的工作。同时，这种模式部署灵活，非常适合大型开发团队或者拥有安全专家的企业。4. 常用的安全检查手段与方法（参考）测评项测评内容测评方法部署与基础结构网络是否提供了安全的通信部署拓扑结构是否包括内

26、部的防火墙部署拓扑结构中是否包括远程应用程序服务器基础结构安全性需求的限制是什么目标环境支持怎样的信任级别网络/系统/数据库漏洞扫描渗透性测试输入/输出和编码如何验证输入是否清楚入口点是否清楚信任边界是否验证Web页输入是否对传递到组件或Web服务的参数进行验证是否验证从数据库中检索的数据是否将方法集中起来是否依赖客户端的验证应用程序是否易受SQL注入攻击应用程序是否易受XSS攻击应用程序是否易受OS注入攻击应用程序是否易受Cookie定制/隐藏文件操纵攻击如何处理输入输出信息是否涉及泄密数据编码处理过程是否存在安全漏洞代码安全性测试工具软件安全功能测试身份验证是否区分公共访问和受限访问是否明

27、确服务帐户要求如何验证调用者身份如何验证数据库的身份是否强制试用帐户管理措施代码安全性测试工具软件安全功能测试访问授权如何向最终用户授权如何在数据库中授权应用程序如何将访问限定于系统级资源代码安全性测试工具软件安全功能测试配置管理是否支持远程管理是否保证配置存储的安全是否隔离管理员特权软件安全功能测试敏感数据是否存储机密信息如何存储敏感数据是否在网络中传递敏感数据是否记录敏感数据软件安全功能测试网络流量分析工具会话管理如何交换会话标识符是否限制会话生存期如何确保会话存储状态的安全代码安全性测试工具软件安全功能测试加密为何使用特定的算法如何确保加密密钥的安全性密码分析工具参数操作是否验证所有的输入参数是否在参数过程中传递敏感数据是否为了安全问题而使用HTTP头数据代码安全性测试工具软件安全功能测试异常管理是否使用结构化的异常处理是否向客户端公开了太多的信息代码安全性测试工具软件安全功能测试审核和日志记录是否明确了要审核的活动是否考虑如何流动原始调用这身份日志审计分析工具软件安全功能测试源代码错误缓冲区溢出漏洞。字符串格式化漏洞。优先权提升漏洞。代码安全性测试工具