首页 > 国家标准(GB) > GB/T 34943-2017 CC++语言源代码漏洞测试规范
GB/T 34943-2017

基本信息

标准号: GB/T 34943-2017

中文名称:CC++语言源代码漏洞测试规范

标准类别:国家标准(GB)

标准状态:现行

出版语种:简体中文

下载格式:.rar .pdf

下载大小:2625KB

相关标签: 语言 漏洞 测试 规范

标准分类号

关联标准

出版信息

相关单位信息

标准简介

GB/T 34943-2017 CC++语言源代码漏洞测试规范 GB/T34943-2017 标准压缩包解压密码:www.bzxz.net

标准图片预览






标准内容

ICS_35.080
中华人民共和国国家标准
GB/T34943—2017
C/C十+语言源代码漏洞测试规范Source code vulnerability testing specification for C/C+ +2017-11-01发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2018-05-01实施
规范性引用文件
术语和定义
缩略语
源代码漏洞测试总则
源代码漏洞测试目的
源代码漏洞测试过程
源代码漏洞测试管理
源代码漏洞测试工具
源代码漏洞测试文档
6源代码漏洞测试内容
源代码漏洞分类
源代码漏洞说明
附录A(资料性附录)C/C+十语言源代码漏洞测试案例附录B(资料性附录)C/C十十语言源代码漏洞类别与名称参考文献
GB/T34943—2017
iKAoNi KAca
iiKANiKAca
本标准按照GB/T1.1一2009给出的规则起草GB/T34943—2017
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口。本标准起草单位:珠海南方软件网络评测中心、珠海中慧微电子有限公司,广东省科技基础条件平台中心、中国电子技术标准化研究院、上海端玛计算机科技有限公司、南昌金庐软件园软件评测培训有限公司、国家应用软件产品质量监督检验中心、珠海市软件行业协会、东信和平科技股份有限公司、南京大学。
本标准主要起草人:侯建华、邓人逊、王忠福、黄兆森、杨尚沅、张肠、赵昌平、张子良、李璐、肖枭、陈振宇、张玉霞、梁建新,蒋蜀鹏、周悦,任佩、杨雪君。HiiKAoNiKAca
GB/T34943—2017
C语言是一种面向过程的程序设计语言,广泛应用于系统软件与嵌入式软件的开发。本标准的C语言语法遵循ISO/IEC9899:2011。C十十语言是一种面向对象的程序设计语言,它在C语言的基础上发展而来,与C语言具有许多相同的语法,广泛应用于系统软件与应用软件的开发。本标准的C十十语言语法遵循ISO/IEC14882:2011语法标准。众所周知,由于各种人为因素影响,每个软件的源代码都难免会存在漏洞,而软件信息泄露、数据或代码被恶意篡改等安全事件的发生一般都与源代码漏洞有关。为尽量减少C/C十十语言源代码中存在的漏洞,有必要制定针对C/C十十语言程序的源代码漏洞测试规范。
源代码漏洞测试可在开发过程的软件编码活动之后实施,也可在运行和维护过程中实施。本标准的漏洞分类与漏洞说明主要参考了MITRE公司发布的CWE(CommonWeaknessEnu-meration),同时结合了当前行业主流的自动化静态分析工具在测试实践中发现的典型漏洞来确定并进行说明。
注:本标准漏洞参考了CWE2.9版本,示例代码适用于本标准选择的案例。本标准仅针对自动化静态分析工具支持的关键漏洞进行说明,应用本标准开展源代码漏洞测试时应根据实际需要对漏洞进行裁剪和补充IV
iiiKANiKAca
1范围
C/C++语言源代码漏洞测试规范
本标准规定了C/C十十语言源代码漏洞测试的测试总则和测试内容GB/T34943—2017
本标准适用于开发方或第三方机构的测试人员利用自动化静态分析工具开展的C/C十十语言源代码漏洞测试活动,C/C十十语言的程序设计和编码人员以及源代码漏洞测试工具的设计人员也可参考使用。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。GB/T11457信息技术软件工程术语GB/T15532—2008计算机软件测试规范GB/T20158一2006信息技术软件生存周期过程配置管理(ISO/IECTR15846:1998.IDT)3术语和定义
GB/T11457界定的以及下列术语和定义适用于本文件。3.1
访问控制
access control
一种保证数据处理系统的资源只能由被授权主体按授权方式进行访问的手段。[GB/T25069—2010,定义2.2.1.42]3.2
攻击attack
在信息系统中,对系统或信息进行破坏、泄露、更改或使其丧失功能的尝试(包括窃取数据)。[GB/T25069—2010,定义2.2.1.58]3.3
cipher block chaining
密码分组链接
对信息加密时,每一密文块在加密时都依赖于前一密文块的方式3.4
密文ciphertext
利用加密技术,经变换,信息内容被隐藏起来的数据[GB/T25069—2010,定义2.2.2.105]3.5
解密decryption
将密文转换为明文的处理,即加密对应的逆过程。GB/T25069—2010.定义2.2.2.691
-iiKAoNniKAca
GB/T34943—2017
字典式攻击dictionaryattack
用遍历给定口令或密钥列表的方式对密码系统的攻击。如,使用存储的特定口令值或密钥值列表或使用来自自然语言字典中的单词列表[GB/T25069—2010,定义2.2.2.239]3.7
domainnameserver(DNS)spoofing域名服务器(DNS)欺骗
攻击者充域名服务器的一种欺骗行为3.8
encryption
对数据进行密码变换以产生密文的过程。一般包含一个变换集合,该变换使用一套算法和一套输人参量。输入参量通常被称为密钥。[GB/T25069—2010.定义2.2.2.60]]3.9
硬编码hard-coding
在软件实现上,把输入或输出的相关参数直接编码在源代码中,而不是从外部来源获得的数据生成的。
散列值hash-value
散列/杂凑函数的输出的比特串。[GB/T25069—2010,定义2.2.2.169]3.11
散列/杂凑函数hashfunction
将比特串映射为固定长度的比特串的函数,该函数满足下列两特性:对于给定输出,找出映射为该输出的输人,在计算上是不可行的;对于给定输人,找出映射为同一输出的第二个输人,在计算上是不可行的。注:计算上的可行性取决于特定安全要求和环境。[GB/T25069—2010.定义2.2.2.166]3.12
堆heap
用于动态内存分配的内存空间。3.13
注入injection
由于字符过滤不严谨导致的漏洞。3.14
one-way encryption
单向加密
一种加密,它只产生密文,而不能将密文再生为原始数据。[GB/T25069—2010.定义2.2.2.9]3.15
最优非对称加密填充
optimal asymmetricencryption paddingRSA算法的一种加密填充方案,可将原有的确定性的加密方案转换成一种可能性方案,并能防止2
-iiiKAoNniKAca
密文的部分解密或其他信息泄露。3.16
填充padding
对数据串附加额外比特。
[GB/T25069—2010,定义2.2.2.187]3.17
口令password
用于身份鉴别的秘密的字、短语、数字或字符序列,通常是被默记的弱秘密。[GB/T25069—2010,定义2.2.2.76]3.18
明文plaintext
未加密的信息。
[GB/T25069—2010,定义2.2.2.135]]3.19
彩虹表
rainbowtable
GB/T349432017免费标准bzxz.net
个用于加密散列函数逆运算的预先计算好的表,常用于破解加密过的密码散列。3.20
反向域名解析
reverse DNS resolution
通过IP地址查询服务器域名。
盐值salt
作为单向函数或加密函数的二次输人而加入的随机变量,可用于导出口令验证数据。3.22
种子seed
一种用作某一确定性随机比特生成器输人的比特串。DRBG的部分状态由种子确定。[GB/T25069—2010.定义2.2.2.232]3.23
敏感信息
sensitive information
由权威机构确定的必须受保护的信息,该信息的泄露、修改、破坏或丢失会对人或事产生可预知的损害。
[GB/T25069—2010,定义2.2.4.7]3.24
source code vulnerability
源代码漏洞
存在于软件源代码中的漏洞。
vulnerability
计算机信息系统在需求,设计,实现,配置,运行等过程中,有意或无意产生的缺陷。这些缺陷以不同形式存在于计算机信息系统的各个层次和环节之中,如果利用不当,会对计算机信息系统的安全造成损害,从而影响计算机信息系统的正常运行。注:改写GB/T28458—2012,定义3.2。4缩略语
下列缩略语适用于本文件。
iiKAoNiKAca
GB/T34943—2017
DNS:域名服务器(DomainNameServer)DRBG:确定性随机比特生成器(DeterministicRandomBitGenerator)IP:网际协议(InternetProtocol)PRNG:伪随机数生成器(PseudorandomNumberGenerator)SQL:结构化查询语言(StructuredQueryLanguage)5源代码漏洞测试总则
源代码漏洞测试目的
源代码漏洞测试的目的是:
发现、定位及解决软件源代码中的漏洞:a
b)为软件产品的安全性测量和评价提供依据。5.2源代码漏洞测试过程
5.2.1概述
源代码作为软件产品的重要组成部分,其测试过程基本等同软件产品的测试过程。本标准遵循GB/T15532一2008的要求将源代码测试过程分为测试策划、测试设计,测试执行和测试总结四个阶段。
5.2.2测试策划
测试策划主要对整个源代码漏洞测试的过程进行策划。测试策划应确定测试的目标,范围,依据、环境和工具,应分析与评估测试风险,并制定应对措施。测试策划应重点明确源代码漏洞测试应划分的阶段以及各阶段的人员角色,任务,时间和工作成果,形成源代码漏洞测试进度计划表。源代码漏洞测试进度计划见表1。
表1源代码漏洞测试进度计划
测试阶段
测试策划
测试设计
测试执行
测试总结
5.2.3测试设计
人员角色
工作成果
《测试计划》
《测试说明》
《测试日志》
《测试总结报告》
测试设计应根据测试目标,结合被测源代码的业务和技术特点,明确测试环境和工具,确定测试需求,测试方法,测试内容,测试准人条件和测试准出条件。测试方法应采用自动化静态分析工具扫描和人工分析相结合的方法。C/C十十语言源代码漏洞测试的测试内容宜包括但不限于以下源代码漏洞分类:
行为问题;
路径错误;
数据处理;
错误的API协议实现;
劣质代码;
f)不充分的封装;
g)安全功能:
h)Web问题
以上8类源代码漏洞分别对应6.1源代码漏洞相关分类。GB/T34943—2017
若被测源代码采用了C/C十十语言的第三方框架,测试人员应根据被测源代码的实际情况在测试内容中增加第三方框架相关的漏洞。应设计测试用例。源代码漏洞测试的测试用例应包括但不限于以下要素:a)名称和编号;
b)自动化静态分析工具的操作步骤和参数配置:c)自动化静态分析工具的期望操作结果5.2.4测试执行
测试执行包括自动化静态分析工具扫描和人工分析应根据测试用例明确的操作步骤,使用自动化静态分析工具执行测试,记录测试执行过程及测试结果。
应对自动化静态分析工具的测试结果进行人工分析,人工分析宜包括但不限于以下任务a)宜按漏洞类别或漏洞风险级别从高到低的顺序分析扫描得到的所有源代码漏洞;结合源代码的上下文和业务需求,验证疑似漏洞,筛除误报的源代码漏洞;b)
c)与开发人员沟通确认源代码漏洞分析结果。5.2.5测试总结
测试总结应对整个源代码漏洞测试过程进行总结,测试总结应包括但不限于以下任务:a)核查测试环境、工具、内容、方法和结果是否正确;b)确认测试目标和测试需求是否得到满足;总结测试内容、方法和结果,出具测试报告。c)
5.3源代码漏洞测试管理
5.3.1过程管理
应对源代码漏洞测试的过程进行管理,一般包括:a)提出源代码漏洞测试各个阶段的任务要求和质量要求。b)安排对源代码漏洞测试的过程进行质量监督和阶段评审,包括监督和评审所需的环境、设备、资金和人员,质量监督的记录应形成文档。对源代码漏洞测试的风险进行管理,提供风险规避所需的相关资源c
d)提供完成源代码漏洞测试各项任务所需的资源保障。包括测试的环境、工具、资金和人员。表2给出了源代码漏洞测试的人员配备的参考。表2源代码漏洞测试人员配备情况表工作角色
测试项目负责人
测试设计员
具体职责
管理监督测试项目,提供技术指导,获取适当的资源,制定基线,技术协调,负责项目的安全保密,过程管理和质量管理,负责测试策划和测试总结开展测试需求分析,确定测试内容、测试方法、测试(软、硬件)环境、测试工具,设计测试用例,建立测试环境
GB/T34943—2017
工作角色
测试员
测试分析员
测试系统管理员
配置管理员
测试评审员
表2(续)
执行测试,记录测试过程和结果具体职责
对自动化静态分析工具的测试结果进行人工分析对测试环境和资产进行管理和维护设置、管理和维护测试配置管理数据库对测试的各个阶段进行评审
注1:当软件的供方实施测试时,配置管理员由软件开发项目的配置管理员承担:当独立的测试组织实施测试时,需配备测试活动的配置管理员注2:一个人可承担多个角色的工作,一个角色可由多个人承担。5.3.2过程评审
5.3.2.1概述
源代码漏洞测试包括测试策划、测试设计、测试执行和测试总结四个阶段。每个测试阶段结束时应开展阶段评审。评审的级别和参加人员要求宜根据被测源代码的重要程度而确定。2测试策划评审
完成测试策划后,应对测试计划进行评审,形成测试策划评审表。评审的具体内容应包括:a)评审测试环境、工具等测试实施条件要素考虑是否全面合理;b)评审测试人员分工和进度计划等测试组织要素是否具有可实施性;c)
评审风险分析是否全面合理以及是否具有可行的应对风险的措施。3测试设计评审
完成测试设计后,应对测试说明和测试就绪情况进行评审,形成测试设计评审表。评审的具体内容应包括:
评审测试需求分析是否合理;
评审测试内容和方法是否符合测试需求:b)
评审测试用例的操作步骤和参数配置是否详细、正确、可实施;评审测试用例的期望结果描述是否准确:评审测试人员、环境和工具是否齐备并符合要求。测试执行评审
完成测试执行后,应对测试日志进行评审,形成测试执行评审表。评审的具体内容应包括:评审测试用例执行是否完整;
评审操作结果是否真实有效;
评审操作结果描述是否清晰、准确;对于与预期结果不一致的操作结果,评审是否记录了详细的问题现象;d)
评审人工分析的结果是否正确。测试总结评审
完成测试总结后,应对测试总结报告进行评审,形成测试总结评审表。评审的具体内容应包括:6
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。