代码安全系统性检测指导建议要求规范

应用安全性测试指导规范（初稿）1.进行应用安全性测试的场景安全性测试的目的是验证集成在软件内的保护机制与否能够在实际环境中保护系统的安全性。从严格意义上，应用系统的安全性将涉及到应用的设计、开发和布署这三个重要环节，因而抱负化的应用安全性测试应是与整个软件开发过程紧密集成的，即在软件设计、开发、测试和布署的过程中动态检测程序代码的安全性，并在应用最后布署之后进行全方面的安全性测评。只有将应用和代码安全的管理融入到应用开发、布署、运维的各环节中，才干确保应用系统的安全性。在应用系统上线并进入运维阶段之后，也需要在维护性开发过程中进行类似的代码安全性测试，并在日常的应用维护过程中动态进行应用整体安全性的评测。代码安全性作为应用安全性中的一种核心的内容，是保障代码开发安全性的一种重要的举措，在开发活动结束的节点上应重点加强。而应用开发完毕后的布署和运维环节中，还将涉及到应用系统整体安全性评定的其它内容（涉及网络安全、操作安全、权限安全、数据安全等）。应用安全性测试的有关文档应纳入项目管理和运维管理的文档管理体系。1.1早期的应用安全性测试场景在传统的软件开发管理模式中引入应用安全测试将需要一种逐步的过程，在早期建议在以下的应用场景下，对目的应用系统的安全性进行测试：应用开发阶段新应用软件开发完毕，通过开发团体内部测试，即将交付验收测试之前，应组织对应用代码进行安全性测试。新应用软件布署完毕之后，应组织对目的应用系统进行整体的安全性测评。应用维护阶段应用软件在维护性开发完毕，通过维护团体内部测试，即将交付验收测试之前，应组织对维护开发所涉及部分的代码安全性进行测试。应用软件维护性开发部分布署或系统软硬件架构重大变更实施完毕之后，应组织对目的应用系统受影响部分进行安全性补充测评。1.2目的的应用安全性测试有关场景而从更完整意义上的应用系统整个生命周期各阶段中，需要进行的应用系统安全性测试、评定的工作可大致规划以下（供参考）：应用设计阶段应用项目立项时，应明确系统的安全目的和安全功效需求，并通过顾客方的（建设方案）评审。应用软件设计方案中应增加系统安全性设计部分，细化目的系统的安全目的和安全功效，并通过顾客方组织的（实施方案）评审。应用软件测试方案中应增加系统安全性测试内容，提供细化的安全性测试方案，并通过顾客方组织的（测试方案）评审。应用开发阶段在应用代码开发的自测和集成测试阶段，运用IDE整合的代码分析工具，对开发的代码安全性进行动态评定。（项目团体自评）新应用软件开发完毕，通过开发团体内部测试，即将交付验收测试之前，应组织对应用代码进行安全性测试。（第三方代码安全测评）应用上线阶段新应用软件布署完毕之后，应组织对目的应用系统进行整体的安全性测评（根据安全测试方案）及整治。（第三方应用安全整体测评）应用维护阶段应用软件在维护性开发完毕，通过维护团体内部测试，即将交付验收测试之前，应组织对维护开发所涉及部分的代码安全性进行测试。应用软件维护性开发部分布署或系统软硬件架构重大变更实施完毕之后，应组织对目的应用系统受影响部分进行安全性补充测评。应用日常维护过程中，应根据应用安全等级，定时进行应用安全性评测和改善。（例行应用安全测评）2.应用安全性测试的范畴与内容应用安全性测试的范畴与内容，应涉及以下几个方面：测评项测评内容布署与基础构造网络与否提供了安全的通信布署拓扑构造与否涉及内部的防火墙布署拓扑构造中与否涉及远程应用程序服务器基础构造安全性需求的限制是什么目的环境支持如何的信任级别输入/输出和编码如何验证输入与否清晰入口点与否清晰信任边界与否验证Web页输入与否对传递到组件或Web服务的参数进行验证与否验证从数据库中检索的数据与否将办法集中起来与否依赖客户端的验证应用程序与否易受SQL注入攻击应用程序与否易受XSS攻击应用程序与否易受OS注入攻击应用程序与否易受Cookie定制/隐藏文献操纵攻击如何解决输入输出信息与否涉及泄密数据编码解决过程与否存在安全漏洞身份验证与否分辨公共访问和受限访问与否明确服务帐户规定如何验证调用者身份如何验证数据库的身份与否强制试用帐户管理方法访问授权如何向最后顾客授权如何在数据库中授权应用程序如何将访问限定于系统级资源配备管理与否支持远程管理与否确保配备存储的安全与否隔离管理员特权敏感数据与否存储机密信息如何存储敏感数据与否在网络中传递敏感数据与否统计敏感数据会话管理如何交换会话标记符与否限制会话生存期如何确保会话存储状态的安全加密为什么使用特定的算法如何确保加密密钥的安全性参数操作与否验证全部的输入参数与否在参数过程中传递敏感数据与否为了安全问题而使用HTTP头数据异常管理与否使用构造化的异常解决与否向客户端公开了太多的信息审核和日志统计与否明确了要审核的活动与否考虑如何流动原始调用这身份源代码错误缓冲区溢出漏洞。字符串格式化漏洞。优先权提高漏洞。3.应用安全性验收的流程与办法3.1应用安全性验收的流程应用安全性验收的流程图以下：3.1.1IT项目安全测评保护规定管理（1）《上海电信内部IT系统的分级安全保护规定》的编制与复审规划处牵头，会同各应用域及信息中心、移动业务支撑中心共同编制《上海电信内部IT系统的分级安全保护规定》。规划处负责定时组织对编制的《IT系统分级保护规定》进行评定和复审，确保该规定能反映业务需求的变化，并适应于现在的内部IT基础架构现状。（2）《上海电信内部IT系统安全保护评定指南》的编制与复审规划处负责牵头并会同有关的安全测评服务商，根据《IT系统分级保护规定》细化并制订《上海电信内部IT系统安全保护评定指南》，作为各IT项目验收环节系统安全保护能力测评与验收的参考基准。规划处在《IT系统分级保护规定》变更后，应及时组织对《IT系统安全保护评定指南》文档做对应调节与更新。3.1.2IT项目安全测评管理（1）安全测评方案编制与评审在IT项目的实施方案编制阶段，由电信项目经理牵头，组织有关应用域、IT项目承建方、第三方安全测评服务商根据《上海电信内部IT系统安全保护评定指南》共同编制该IT项目的安全测评方案。项目安全测评方案编制完毕后，应和项目实施方案一同进行实施方案的评审环节。（2）IT项目安全测评IT项目承建方在完毕项目建设实施工作后，在正式提出项目验收请求之前，向第三方安全测评服务商申请进行项目安全测评。第三方安全测评服务商将按照评审通过的项目安全测评方案，组织现场安全测评，汇总测评成果并提出安全整治意见给IT项目承建方和电信项目经理。IT项目承建方在接到项目安全整治意见后，应及时组织针对性的安全整治工作，并向第三方测评服务商申请整治复审。第三方测评服务商在收到整治复审申请后，针对整治意见进行复审测评，直至全部整治项均符合规定。全部测评项通过后，第三方测评服务机构出具项目安全测评报告，并汇总测评有关技术文档提交至电信项目经理。电信项目经理在收到项目安全测评报告后，组织常规的IT项目验收工作，并在项目验收时将安全测评有关文档并入项目技术文档保存。（3）IT项目的移交在IT项目建设完毕后的维护移交阶段，应同时将应用系统的安全规定和安全保护指南转换为对应的《应用系统安全维护指南》，作为应用维护阶段的安全维护基准。3.1.3IT项目运维安全测评管理（1）维护性开发的安全测评在维护性开发工作启动阶段应参考《应用系统安全维护指南》拟定维护性开发有关部分的安全保护评定指南，并细化为对应的安全测试方案，作为维护性开发结束的安全评定的基准。维护性开发工作结束，由移动业务支撑中心牵头，组织有关应用域、维护服务提供商、第三方安全测评服务商共同完毕维护性开发涉及部分系统的安全测评和整治，并作为维护性开发验收的必要条件之一。（2）日常维护安全测评移动业务支撑中心应根据《应用系统安全维护指南》，组织第三方安全测评服务商按照应用系统的分级安全保护规定进行定时的系统安全测评，并根据测评成果对IT基础架构、应用系统进行必要的安全改善。应用系统的日常安全维护文档也纳入维护文档管理体系。3.2应用安全性测试的办法3.2.1测试办法概述应用安全性测试与验收的办法重要涉及：静态的代码安全测试（白盒法）：重要通过对源代码进行安全扫描，根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对，从中找出代码中潜在的安全漏洞。该办法非常有用，可在编码阶段找出全部可能存在安全风险的代码，这样开发人员能够在早期解决潜在的安全问题。静态代码测试更合用于早期的代码开发阶段，而不是测试阶段。动态的渗入测试（黑盒法）：渗入测试也是惯用的安全测试办法。是使用自动化工具或者人工的办法模拟黑客的输入，对应用系统进行攻击性测试，从中找出运行时刻所存在的安全漏洞。该测试办法的特点是真实有效，普通找出来的问题都是对的的，也是较为严重的。但渗入测试一种致命的缺点是模拟的测试数据只能达成有限的测试点，覆盖率很低。程序数据扫描：普通是进行内存测试，内存测试能够发现许多诸如缓冲区溢出之类的漏洞，而这类漏洞使用除此之外的测试手段都难以发现。该测试办法重要用于确保有高安全性需求应用在运行过程中的数据安全性。数据扫描畅通需要专门的工具来进行验证。3.2.2应用安全测试的成功要素成功的应用安全测试需要做好以下方面的充足准备：充足理解软件安全漏洞：评定一种软件系统的安全程度，需要从设计、实现和布署三个环节同时着手。这一点可参考通用评定准则（CommonCriteria）的软件系统安全评定办法来理解：首先要拟定软件产品对应的ProtectionProfile（PP,产品的安全特性模板），然后根据PP再提出具体的安全功效需求，最后拟定安全对象以及是如何满足对应的安全功效需求的。因此，一种安全软件的三个环节，哪个出问题都不行，需要充足理解各环节的软件安全漏洞。安全性测试的评定：需要建立对测试后的安全性评定机制，普通可从以下两个方面进行评定：安全性缺点数据评定：直接分析评定目的代码，如果发现软件的安全性缺点和漏洞越多，可能遗留的缺点也越多。进行这类评定时，必须建立基线数据作为参考，否则评定起来没有根据就无法得到对的的结论。采用漏洞植入法来进行评定：通过在目的代码中植入某些有安全漏洞，然后测试可发现的植入漏洞，并以此来评定软件的安全性测试做得与否充足。采用安全测试技术和工具：可使用专业的含有特定功效的安全扫描软件来寻找潜在的漏洞，将已经发生的缺点纳入缺点库，然后通过自动化测试办法来使用自动化缺点库进行轰炸测试。3.2.3反向安全测试与正向安全测试（1）反向安全性测试过程大部分软件的安全测试都是根据缺点空间反向设计原则来进行的，即事先检查哪些地方可能存在安全隐患，然后针对这些可能的隐患进行测试。因此，反向测试过程是从缺点空间出发，建立缺点威胁模型，通过威胁模型来寻找入侵点，对入侵点进行已知漏洞的扫描测试。其优点是可对已知的缺点进行分析，避免软件里存在已知类型的缺点；缺点是对未知的攻击手段和办法普通会无能为力。反向安全性测试的常规过程将涉及：建立缺点威胁模型。建立缺点威胁模型重要是从已知的安全漏洞入手，检查软件中与否存在已知的漏洞。建立威胁模型时，需要先拟定软件牵涉到哪些专业领域，再根据各个专业领域所碰到的攻击手段来进行建模。寻找和扫描入侵点。检查威胁模型里的哪些缺点可能在本软件中发生，再将可能发生的威胁纳入入侵点矩阵进行管理。如果有成熟的漏洞扫描工具，那么直接使用漏洞扫描工具进行扫描，然后将发现的可疑问题纳入入侵点矩阵进行管理。入侵矩阵的验证测试。创立好入侵矩阵后，就能够针对入侵矩阵的具体条目设计对应的测试用例，然后进行测实验证。（2）正向安全性测试过程为了规避反向设计原则所带来的测试不完备性，需要一种正向的测试办法来对软件进行比较完备的测试，使测试过的软件能够防止未知的攻击手段和办法。正向安全性测试过程普通涉及：先标记测试空间。对测试空间的全部的可变数据进行标记，由于进行安全性测试的代价高昂，其中要重点对外部输入层进行标记。例如，需求分析、概要设计、具体设计、编码这几个阶段都要对测试空间进行标记，并建立测试空间跟踪矩阵。精拟定义设计空间。重点审查需求中对设计空间与否有明拟定义，和需求牵涉到的数据与否都标记出了它的正当取值范畴。在这个环节中，最需要注意的是精确二字，要严格按照安全性原则来对设计空间做精确的定义。标记安全隐患。根据找出的测试空间和设计空间以及它们之间的转换规则，标记出哪些测试空间和哪些转换规则可能存在安全隐患。例如,测试空间愈复杂，即测试空间划分越复杂或可变数据组合关系越多也越不安全。尚有转换规则愈复杂，则出问题的可能性也愈大，这些都属于安全隐患。建立和验证入侵矩阵。安全隐患标记完毕后，就能够根据标记出来的安全隐患建立入侵矩阵。列出潜在安全隐患，标记出存在潜在安全隐患的可变数据，和标记出安全隐患的等级。其中对于那些安全隐患等级高的可变数据，必须进行详尽的测试用例设计。（3）正向和反向测试的区别正向测试过程是以测试空间为根据寻找缺点和漏洞，反向测试过程则是以已知的缺点空间为根据去寻找软件中与否会发生同样的缺点和漏洞，两者各有其优缺点。反向测试过程重要的一种优点是成本较低，只要验证已知的可能发生的缺点即可，但缺点是测试不完善，无法将测试空间覆盖完整，无法发现未知的攻击手段。正向测试过程的优点是测试比较充足，但工作量相对来说较大。因此，对安全性规定较低的软件，普通按反向测试过程来测试即可，对于安全性规定较高的软件，应以正向测试过程为主，反向测试过程为辅。3.2.5软件生命周期中的应用安全确保机制*（这部分属于最后要建立的覆盖软件生命周期的安全确保机制，供参考）在确保应用安全的整个生命周期中，需要涉及多个基本任务，这些任务涉及：设立安全需求(SetSecurityRequirements)：由安全专家或有关人员指定在项目中哪些问题能够被定义为安全漏洞、每种安全漏洞对项目的影响程度。配备(Configure)：针对不同的项目，进行必要的配备以扫描应用。扫描(Scan)：扫描项目代码并返回成果。优选(Triage)：根据扫描的成果进行排选，发现影响最大、需要立刻修复漏洞的过程。解决(Resolve/Remediate)：通过修改代码、增加安全函数、移出缺点等方式修复发现的安全漏洞。验证(Verify)：重新扫描代码以确保安全漏洞已经被对的修复。公司能够根据规模、人力等因素将这些任务和不同的角色相结合，因此在软件开发的生命周期中确保应用安全，就会产生以下三种布署模式。在具体应用时，可根据各项目组的实际状况来灵活选择。（1）简易模式简易模式下，有关角色的职责分别为：管理人员或者安全专家：设立安全需求定义，同时建立验证原则；在项目过程中查看报告，获知安全有关的信息；研发人员：从源代码控制系统中检出代码进行开发；在任何时候都能够自行配备扫描工具进行扫描，并分析扫描成果；决定如何去修复，最后在修复完毕后再次运行扫描，来验证与否修改对的，如果对的，则将代码检入到源代码控制系统，否则继续进行修改。这种模式的优点是易于实现，仅涉及两种角色，管理人员和开发人员。非常适合小规模的开发团体，以及需要进行审计的项目。同时，由于产生交互的环节少，并且由写代码的开发人员自己发现问题，能够更有效的优选和解决安全漏洞。该模式的缺点是不适合大规模布署，增大了开发人员的工作量，对开发人员也提出了更高的规定，他们需要理解一定的安全知识。同时，很难将公司的流程和方略加到代码修复过程中。（2）分布模式该模式将质量管理人员和产品公布团体纳入到应用安全生命周期中。分布模式下，有关角色的职责分别为：管理人员或安全专家：设立安全需求定义；连接到源代码控制系统理解开发进度；审视QA团体提供的评定数据或报告。QA团体或产品公布团体：进行扫描配备，还能够选择将扫描工具和现有的Build系统集成，实现在构建过程中自动加入应用代码安全审计的目的；在设定的里程碑时间点，从源代码控制系统中同时代码并对其进行安全扫描；将扫描完毕的源数据（源数据涉及扫描出来的漏洞信息和源代码的对的版本）发送给开发人员；并将扫描成果形成报告发送给管理团体。开发人员：对发送给自己的安全扫描成果进行优选；根据项目需要选择修复；重新测试以验证并将对的的代码检入到源代码控制系统。分布模式的优点是布署灵活，能够和build过程紧密结合，充足运用自动化的构建过程发现安全漏洞，提高了工作效率，并且QA和产品公布人员承当了一部分的安全诊疗工作，减轻了开发人员工作量的同时，使更多的角色参加到应用安全的范畴中。另外，由QA团体集中产生安全评定报告，也能方便管理团体全方面理解公司的应用安全现状。该模式适合中到大型公司以及但愿加入一定控制方法的应用。但是同样规定开发人员有较强的安全知识。（3）集中模式集中模式下，有关角色的职责分别为：管理人员或者安全专家：设立安全需求定义；连接到源代码控制系统理解开发进度；审视安全分析团体或QA团体提供的评定数据或报告。安全分析团体或QA团体：配备扫描工具，并能够选择和公司的build系统集成；从源代码控制系统中获取最新的代码进行扫描；对扫描成果进行优选；将优选成果根据某种分类打包，提交到公司的缺点跟踪系统中；从缺点跟踪系统中获得漏洞修复的最新状况，形成应用安全报告提交给管理团体；开发人员：从缺点跟踪系统中接受任务，修复代码；重新测试进行验证，并将对的成果检入到源代码控制系统。集中模式和其它模式的区别重要是开发人员不需要承当多出的安全分析工作，只将注意力放在和修复其它缺点同样进行代码修复，由安全分析团体或者QA团体集中承当安全诊疗的工作。这种模式的好处是职责分明，能够和公司现有的系统，如build系统、缺点跟踪系统集成，较好的遵照了公司固有工作模式。并且将安全分析工作集中起来，便于公司集中培训和指导安全人员，使得每个角色在参加到应用安全的同时，不用承当更多的工作。同时，这种模式布署灵活，非常适合大型开发团体或者拥有安全专家的公司。4.惯用的安全检查手段与办法（参考