信息安全技术应用软件安全编程指南(GB-T 38674-2020).pdf

《信息安全技术应用软件安全编程指南(GB-T 38674-2020).pdf》由会员分享，可在线阅读，更多相关《信息安全技术应用软件安全编程指南(GB-T 38674-2020).pdf（140页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、ICS 35.040L80中中 华华 人人 民民 共共 和和 国国 国国 家家 标标 准准信息安全技术 应用软件安全编程指南Information security techniquesGuideline on secure coding ofapplication software(报批稿)（本稿完成日期：2019 年 4 月）在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。XXXX-XX-XX 发布XXXX-XX-XX 实施GB/T XXXXXXXXGB/T XXXXXXXXXI目次前言.II1范围.12规范性引用文件.13术语、定义和缩略语.13.1术语和定义.14概述.4

2、5安全功能实现.45.1数据清洗.45.2数据加密与保护.55.3访问控制.65.4日志安全.86代码实现安全.96.1面向对象程序安全.96.2并发程序安全.106.3函数调用安全.116.4异常处理安全.116.5指针安全.116.6代码生成安全.117资源使用安全.127.1资源管理.127.2内存管理.127.3数据库管理.137.4文件管理.137.5网络传输.148环境安全.158.1第三方软件使用安全.158.2开发环境安全.158.3运行环境安全.16附录A（资料性附录）代码示例.17A.1 概述.17A.2 安全功能实现.17A.3 代码实现安全.49A.4 资源使用安全.1

3、02A.5 环境安全.134参考文献.136GB/T XXXXXXXXXII前言本标准依据 GB/T 1.1-2009 给出的规则起草。本标准由全国信息安全标准化技术委员会(SAC/TC 260)提出并归口。本标准起草单位：国家计算机网络应急技术处理协调中心、北京邮电大学、北京奇虎测腾安全技术有限公司、中国电力科学研究院、上海计算机软件技术开发中心、海通证券股份有限公司、北京银行、信息安全共性技术国家工程研究中心。本标准主要起草人：舒敏、王博、吴倩、王文磊、黄元飞、张家旺、林星辰、陈禹、王鹏翩、李燕伟、高强、杨鹏、陈亮、范乐君、张淼、徐国爱、郭燕慧、李祺、杨昕雨、王晨宇、葛慧晗、黄永刚、韩建、

4、章磊、王彦杰、胡建勋。GB/T XXXXXXXXX1信息安全技术应用软件安全编程指南1范围本标准依据最佳实践提出应用软件安全编程的通用框架，从提升软件安全性的角度针对应用软件编程过程进行规范和指导。依照本标准进行软件开发能有效降低软件安全风险。本标准中的应用软件为针对特定应用开发的业务处理软件。本标准描述对各领域、采用各种编程语言的应用软件普遍适用的通用安全编程规范。本标准主要适用于客户端/服务器架构的应用软件开发，其他架构的应用软件开发也可参照使用，并根据其应用环境的特性补充必要的安全防护措施。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本

5、文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 16264.8-2005 信息技术 开放系统互连 目录 公钥和属性证书框架（ISO/IEC9594-8-2001，IDT）GB/T 25069-2010 信息安全技术术语GB/T 36624-2018 信息技术 安全技术 可鉴别的加密机制GM/T 0028-2014 密码模块安全技术要求ISO/IEC 9798-1:2010 信息技术安全技术实体鉴别 第 1 部分：总则（Informationtechnology-Security techniques-Entity authentication-Part 1:

6、General）ISO/IEC 27034:2011 信息技术安全技术应用安全（Information technology-Securitytechniques-Application security）3术语、定义和缩略语3.1 术语和定义GB/T25069 中界定的下列术语和定义适用于本文件。3.1.1缓冲区溢出 buffer overflow当应用程序向为某特定数据结构分配的内存空间边界之外写入数据时，即会发生缓冲区溢出。注：缓冲区溢出被用来作为一种软件系统的攻击手段，通过往程序的缓冲区写入超出其长度的内容，造成缓冲区溢出，从而破坏程序堆栈，使程序转而执行其它指令，以达到攻击的目的。3

7、.1.2命令注入 commandinjection通过应用程序将用户输入的（恶意）内容拼接到命令中，并提交给后台引擎执行的攻击行为。3.1.3GB/T XXXXXXXXX2应用软件日志 application softwareLog用于记录系统操作事件的文件集合。3.1.4线程安全 thread safe某个函数、函数库在多线程环境中被调用时能够正确地处理多个线程之间的共享变量，使程序功能正确执行的能力。3.1.5线程同步 thread synchronization多个线程通过特定手段来控制线程之间执行顺序的一种机制。注：当有一个线程在对内存进行操作时，其它线程就不能对该内存地址执行操作，直

8、到该线程操作完成，此时，其它线程被设置处于等待状态。3.1.6死锁 deadlock两个或两个以上的进程在执行过程中，因竞争资源或因彼此通信而造成的一种阻塞现象，此时这些相互等待的进程称为死锁进程，该系统处于死锁状态或者产生了死锁。3.1.7阻塞 block进程/线程暂停执行过程，等待请求被应答的状态。3.1.8游标 cursor一种用于操纵数据库查询返回的多行结果集的机制。3.1.9敏感数据 sensitive data必须受保护的信息，该信息的泄露、修改、破坏或丢失会对人或事产生可预知的损害。常见的敏感数据包括但不限于身份鉴别数据、会话标识符、口令、连接字符串等。3.1.10秘密数据 se

9、cret data为了执行特定安全功能策略，只能由授权用户或被评对象安全功能知晓的信息。3.1.11信任边界 trust boundary由编程人员直接控制的系统部件组成。3.1.12线程挂起 suspend暂停线程运行的操作。在线程挂起后，可以通过重新唤醒线程使之恢复运行。3.1.13GB/T XXXXXXXXX3异常 exception导致程序中断运行的一种指令流。如果不对异常进行正确的处理，则可能导致程序的中断执行。3.1.14错误 error系统运行中出现的非预期问题，可能导致系统崩溃或者暂停运行。3.1.15硬编码 hardcode在编码过程中将可变变量用一个固定数值表示。3.1.1

10、6封装 encapsulation将系统功能、一组数据和在这些数据上的操作隔离在一个模块中，并为该模块提供精确的规格说明的软件开发技术。3.1.17泛型 generictype程序设计语言的一种特性。通过引入参数化数据类型，允许程序员在强类型程序设计语言中定义类型时包含一些可变部分，这些部分在使用前必须作出指明。3.1.18堆污染 heappollution当将一个参数化的数据类型指向一个对象，而该对象不是参数化数据类型，或不是同类型的参数化数据类型时，会产生堆污染。3.1.19嵌套类 nestedclass声明在另一个类（或接口）代码块中的任意类。3.1.20并发程序 concurrent

11、program允许在同一时间段执行多个程序模块的机制，可通过多进程、多线程机制实现。3.2 缩略语下列缩略语适用于本文件。HTTP 超级文本传输协议（HyperText Transfer Protocol）LDAP 轻量目录访问协议（Lightweight Directory Access Protocol）SQL 结构化查询语言（Structured Query Language）SSL 安全套接子层（Secure Sockets Layer）TLS 传输层安全（Transport Layer Security）UTF-8 针对 Unicode 的可变长度字符编码（8-bit Unicode

12、 Transformation Format）XML 可扩展置标语言（Extensible Markup Language）GB/T XXXXXXXXX44概述本指南从程序安全和环境安全两个方面提出了提升应用软件安全性的编程最佳实践。其中，程序安全部分描述软件在资源使用、代码实现、安全功能方面的安全技术规范，环境安全部分描述软件的安全管理配置规范。图 1 为本标准描述的应用软件编程安全框架。图1应用软件编程安全框架5安全功能实现5.1 数据清洗5.1.1输入验证应用软件应确保对所有输入到应用的数据进行验证，拒绝接受验证失败的数据。在设计和实现数据验证功能时需关注以下方面内容，包括但不限于：a)

13、验证所有输入数据的安全性，包括但不限于以下方面的验证：检测输入数据的数据类型。检测输入数据的长度，验证允许输入的最小和最大长度。检测输入数据的值，包括进行最小值、最大值边界值检查。参考 7.4(c)验证文件的安全性。b)应特别关注如下场景的数据验证：验证来自 HTTP 请求中的所有数据，恶意数据可以从表单域，URL 参数，cookie，HTTP 头以及 URL 自身传入。验证来自重定向输入的数据。攻击者可能向重定向的目标直接提交恶意代码，从而避开应用程序逻辑以及在重定向前执行的验证，所以对重定向输入数据应再次验证。对来自命令行、环境以及配置文件的输入进行校验。GB/T XXXXXXXXX5对发

14、送给文件系统、浏览器、数据库或者其他系统的命令进行验证，防止采用不可信来源的数据构建命令。c)对重要业务操作相关的输入数据，应验证数据的真实性和完整性，宜验证数据发送方的数字签名，以确认数据发送方的身份。d)对输入的数据进行过滤或标准化处理，然后进行验证。e)禁止试图对验证失败的数据进行修复，自动错误恢复代码很可能改变请求的初始意图或者截断验证逻辑。f)在可信任环境中执行输入验证。g)集中输入验证，把输入验证作为软件框架的一部分，为应用程序提供一个统一的输入验证策略。h)为所有输入明确恰当的字符集，比如：UTF-8。确定系统是否支持 UTF-8 扩展字符集，如果支持，在 UTF-8 解码完成以

15、后进行输入验证。i)在程序中定义清晰的信任边界，将可信和不可信数据（比如：数据库，文件流）分别存储。当数据要从不可信的一侧传输到可信一侧的时候，应使用验证逻辑进行判断。相关的规范和不规范的代码示例参见附录 A.2.1.1。5.1.2输出净化应用软件应对所有输出到客户端的，来自于应用程序信任边界之外的数据进行净化。应用软件在设计和实现输出净化功能时需关注以下方面内容，包括但不限于：a)除非明确对目标编译器是安全的，否则对所有字符进行编码。b)在可信任环境中执行输出编码。c)应以国际、国家、行业标准为基础，结合实际情况制定编码规则。d)关注 SQL、XML 和 LDAP 查询语句以及操作系统命令，

16、这些命令可能存在潜在的危险字符，应语义净化。e)应禁止将 URL 重定向到用户可控的不可信站点。相关的规范和不规范的代码示例参见附录 A.2.1.2。5.2 数据加密与保护5.2.1加密规范应用软件应对敏感数据进行加密保护，数据加密的设计和实现需关注以下方面内容，包括但不限于：a)凡涉及采用密码技术解决保密性、完整性、真实性、不可否认性需求的，须遵循国家有关法律法规。b)即使在服务器端，仍然要加密存储敏感数据。c)在可信任环境中执行数据的加密过程。d)确保密码运算过程安全。应基于指定的算法和特定长度的密钥来进行密码运算。e)安全地处理加密模块的失败操作。如果加密模块加密失败或报错，需重新加密。

17、f)应当按照用途尽量减少需要保存的秘密信息。g)建立并使用相关的安全策略和流程以实现加、解密的密钥管理。h)使用安全的随机数生成器：应采用能产生充分信息熵的算法或方案。避免将具有密码学弱点的伪随机数生成器（PRNG）用于加密场景。GB/T XXXXXXXXX6使用密码学的伪随机数生成器时，应使用信息熵最大的信息作为密码学伪随机数生成器的种子。如果信息熵不可用，可使用变化的种子来降低安全威胁，但应避免使用可预测的种子（如进程 ID 或系统时间的当前值）、或空间太小的种子。i)维护密钥的安全：应规定安全的密钥强度，仅使用高于规定强度的密钥。应规定密钥有效期，禁止使用已经过期的密钥。禁止使用硬编码密

18、钥，硬编码密钥将显著增加加密数据被攻击者破解的可能性。相关的规范和不规范的代码示例参见附录 A.2.2.1。5.2.2数据保护应用软件应从以下方面保护数据的安全，包括但不限于：a)应明确应用软件中的敏感数据、隐私数据的范围，以及有权访问这些数据的用户范围。b)在软件中明确划定信任边界，禁止敏感数据跨越信任边界。c)对数据的授权访问遵循最小权限原则。d)应参照 5.2.1 节的内容对敏感数据进行加密存储和传输。e)对重要数据进行完整性检查。f)尽量缩短敏感数据的存储时间，并减少敏感数据的存储地点，以降低敏感数据泄露的风险。g)避免在错误消息、进程信息、调试信息、日志文件、源代码或注释中包含敏感数

19、据。h)在设计 WEB 登录表单的时候，可考虑禁止浏览器的口令自动填充功能。i)资源释放前应清理敏感数据。j)保护所有在服务器上缓存的或临时拷贝的敏感数据，并在不需要时尽快清除。k)禁止在客户端保存敏感数据。l)当敏感数据丢失或破坏时，确保可通过备份数据进行数据恢复。m)在将数据发送到客户端的时候，应基于任何通过客户端共享的数据都是不安全的假设对数据进行操作。相关的规范和不规范的代码示例参见附录 A.2.2.2。5.3 访问控制5.3.1身份鉴别身份鉴别的设计和实现应注意以下方面内容，包括但不限于：a)建立并使用标准的、已通过测试的身份鉴别策略，如可参照 ISO/IEC 9798-1:2010

20、信息技术安全技术实体鉴别 第 1 部分：总则 中的要求设计和实现身份鉴别策略。b)根据业务安全要求选择身份鉴别方式，安全性要求高的系统建议采用多因素身份鉴别方式。c)为所有身份鉴别使用一个集中实现的方法，包括利用库文件请求外部身份鉴别服务。d)所有的身份鉴别过程必须在可信任环境中执行，且在每次用户登录时进行身份鉴别。避免仅在客户端而非服务器端执行身份鉴别。e)最小化角色授权，一个账号对应一个人而不是一个组，使用软件的每个人应拥有唯一的用户名。f)避免依赖不可靠信息进行身份鉴别。在进行关键的安全操作时：不应信任 cookie 中的数据。GB/T XXXXXXXXX7不应依赖反向 DNS 解析获取

21、的主机信息。g)验证数字证书。必须检查证书的状态和证书持有者，只有有效的、未过期的且证书的实际持有者与证书中声明的持有者一致的证书才能被信任和使用。h)避免鉴别过程被绕过：严格控制用户访问系统的可选途径或通道，保证用户只能通过指定的途径或通道访问系统，避免身份鉴别被绕过。应使用安全的鉴别算法，且算法的关键步骤没有被省略或跳过。i)避免在处理身份鉴别的过程中透露多余信息：处理每个认证请求所花费的时间相同。避免攻击者根据登录尝试失败的时间来判断登录尝试是否成功。安全地处理未成功的认证。认证和注册的错误信息不能包含可被攻击者利用的信息，例如，判断一个特定的用户名是否有效的信息。确保鉴别反馈的内容中不

22、包含敏感数据。j)对鉴别尝试的频率进行限制，连续多次登录失败强制锁定账户：限制同一个账号能够进行鉴别尝试的频率和次数。应设定用户登录失败次数的阈值，在用户登录失败次数达到阈值后应锁定用户账号，防止攻击者进行暴力破解。k)如果允许一次身份鉴别后，可进行较长时间的通话，则应周期性地重新鉴别用户的身份，以确保其权限没有改变。如果发生改变，注销该用户，并强制重新执行身份鉴别。l)在用户执行关键或者不可逆的操作（如修改口令）之前，再次鉴别用户身份，以减少不安全会话带来的损失。m)避免使用过于严格的账户锁定机制（账户锁定保护机制过于严格且容易被触发，就允许攻击者通过锁定合法用户的账户来拒绝服务合法的系统用

23、户）。n)实现用户与主体的绑定：用户进程应与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。系统进程应与当前服务要求者用户动态关联，使系统进程的行为可以追溯到当前服务要求者用户。相关的规范和不规范的代码示例参见附录 A.2.3.1。5.3.2口令安全应用软件需从以下方面保护口令的安全，包括但不限于：a)登录过程中，应确保口令不可见。b)使用强口令，口令的复杂度（包括口令组成、口令长度等）应满足安全策略要求。c)禁止使用弱口令、空口令或已泄露的口令。d)对于默认的初始口令，强制用户初次登录时更改默认口令。e)不使用过期口令：过期口令不可继续使用。应定期更改口令，关键系统可要求更频繁

24、地更改。应明确口令更改时间周期。f)保护口令重置信息：应使用保护口令信息的安全策略保护口令重置信息。口令重置操作应采取与账户创建、身份鉴别同等级别的安全控制策略。GB/T XXXXXXXXX8口令重置问题应当支持尽可能随机的提问。g)安全地存储口令：禁止明文存储口令。应使用不可逆的加密算法或单向杂凑函数对口令进行加密存储。在散列过程加入盐，将口令转化为不可还原或难以使用字典攻击猜测的形式。应将加密后的口令存储在配置文件、数据库或者其它外部数据源中。禁止在源代码中写入口令。h)所有的口令加密过程必须在可信任环境中执行。i)尽可能地减少口令、加密密钥的保存时间。j)使用安全的口令传输：禁止在不安全

25、的信道中传输口令，也禁止接受来自不安全信道的口令。禁止传递明文口令。传统协议，如 FTP，TELNET，HTTP，POP 以及 IMAP，应在使用了安全传输协议（例如 SSL）的情况下才可被用于传输口令。k)用户信息改变时使用单独的信道通知：允许用户改变其口令，当用户改变其账号信息时（例如重置口令）需要发送确认信息，确认信息应使用单独的通道发送。可要求用户通过邮件等方式来确认信息的变更，但禁止在确认邮件中包含身份鉴别信息。当用户改变他们的联系信息时，应发送两次变更通知：分别包含旧的和新的信息。相关的规范和不规范的代码示例参见附录 A.2.3.2。5.3.3权限管理应用软件对于权限管理的设计和实

26、现应关注以下方面内容，包括但不限于：a)遵循最小权限原则：服务账户或连接到外部系统的账号，应当具有执行经授权的任务所需的最小权限（或最低的安全许可）。将许可权限尽可能地细化，使用细粒度的访问控制。b)所有的访问授权操作需在可信任环境中执行。c)将访问控制作为集中化程序框架的一部分，建立统一的访问控制策略。d)对每个用户交互都要检测访问控制状态。e)确保访问控制策略检查了用户访问或操作的数据。f)只有授权的用户才能访问秘密数据或敏感数据。通常，这些数据包括但不限于：与用户信息或应用软件自身安全密切相关的状态信息、文件或其他资源、受保护的URL、受保护的功能、直接对象引用、应用程序数据以及与安全相

27、关的配置信息。g)执行账户审计并强制失效长期不使用的账户。建议明确允许账户不使用的最长期限，支持账户的强制失效，并在账户停止时终止会话。相关的规范和不规范的代码示例参见附录 A.2.3.3。5.4 日志安全应用软件日志记录了系统运行状况，通常包括但不限于软硬件故障、系统重要事件等。日志记录的设计和实现需从以下方面提升安全性，包括但不限于：a)保护日志文件：GB/T XXXXXXXXX9应对日志文件进行安全存储，例如将日志文件独立保存于应用程序目录外，使用严格的访问权限来控制日志文件使用。使用消息摘要算法以验证日志记录的完整性。b)在可信任的环境中执行日志记录操作。c)将日志记录作为集中化程序框

28、架的一部分。d)在每个日志条目中增加精确的时间戳，同时确保时间戳的可靠性。e)对每个重要的行为都记录日志：确保系统在发生重要安全事件时创建日志。重要安全事件通常包括但不限于：重要数据更改、认证尝试（特别是失败的认证）、失败的访问控制、失效或者已过期的会话令牌尝试、系统例外、管理功能行为、失败的后端 TLS 链接、加密模块的错误。f)对日志记录进行完善的异常捕获处理，确保即使日志记录过程发生异常，日志记录仍然能够继续正确的执行。g)应对日志中的特殊元素进行过滤和验证。确保日志记录中的不可信数据，不会在查看界面或者运行软件时以代码的形式被执行。h)采取安全措施防止攻击者写任意的数据到日志中。i)避

29、免在日志中保存敏感数据。相关的规范和不规范的代码示例参见附录 A.2.4。6代码实现安全6.1 面向对象程序安全面向对象程序的设计和开发需从以下方面提升软件的安全性，包括但不限于：a)子类对基类的扩展应从以下角度进行安全控制：对基类的扩展，必须保持由基类提供的不变性。对于关键基类仅允许受信任的子类进行扩展。注：不变性是指在程序运行的特定段或一规定点被认为是真（true）的属性。b)修改基类时，必须保证基类中的修改不触动其子类所依赖的程序不变性。c)对类的数据成员进行访问控制：数据成员必须声明为私有。当类成员需要在声明该类的包以外被访问时，使用暴露类成员的封装器方法监视并控制对数据成员的修改。d

30、)避免混用泛型和非泛型的数据类型。如为了兼容遗留代码而混用泛型和非泛型数据类型，需警惕堆污染。e)为可变类实现防御性复制功能，该功能可创建可变类实例的副本，通过此功能允许将可变类实例传递给非受信代码。f)应禁止返回类的私有可变成员的引用。可返回一个指向内部可变成员的防御性副本的引用，从而保护内部状态不会被非预期地修改。g)对可变变量（或可变的内部对象）创建防御性副本：如果程序逻辑依赖可变变量，应警惕竞态攻击。可变变量的特点在于它的数值会发生变化，多次访问该变量会得到不同的值。如果程序逻辑对可变变量进行验证和安全检查后，该变量的值被篡改，就会发生 Time-of-CheckTime-of-Use

31、(TOCTOU)漏洞。GB/T XXXXXXXXX10在需要访问可变变量（或可变的内部对象）时，可使用返回可变变量（或可变的内部对象）的封装器方法来实现。h)禁止复制或者序列化包含秘密或者其他敏感数据的类。i)那些不敏感但是需要维持其他不变性的类，必须对恶意子类访问或者操作它们的数据及破坏其不可变性的可能性做出防御。j)应禁止嵌套类将其所依附的外部类的私有成员暴露给其他外部的类或者包。k)当判定一个对象是否属于特定的类，或两个对象的类是否相同时，应比较类对象，不能仅基于类名称进行判定。l)谨慎处理构造函数抛出异常的情况。在一个构造方法开始创建对象但并未结束时，对象会被部分地初始化。只要对象没有

32、被完全初始化，就必须对其他类不可见。m)应避免将不可序列化的对象存储到磁盘。相关的规范和不规范的代码示例参见附录 A.3.1。6.2 并发程序安全并发程序设计和开发需从以下方面提升软件的安全性，包括但不限于：a)确保共享数据的线程安全：确保所有的全局变量、线程间的共享可变数据是线程安全的。对所有需确保线程安全的数据通过同步方法或代码块进行保护。b)确保共享变量、数据的可见性：对共享变量、数据的读或写操作均应使用同步访问。所有执行读或写操作的线程都必须在同一个锁上同步，以确保所有线程都能看到共享变量或数据的最新值。c)确保同步对象上的锁按相同的顺序获得和释放，以避免当两个或多个线程互相等待时被阻

33、塞进而发生死锁。d)需确保能够终止处于阻塞状态的任务和线程。e)对锁实行严格的访问控制，避免锁被不可信的外部实体影响或控制。f)确保线程池安全：使用线程池来处理请求，以抵御拒绝服务攻击。禁止在一个有限的线程池中执行需要依赖其他线程的任务，以避免死锁。提交至线程池的任务应是可被中断的。所有线程池中的任务应提供将任务执行的异常情况通报应用程序的机制。g)应及时释放线程专有对象，防止内存泄漏与拒绝服务式攻击。h)注意共享对象的存储周期，禁止在一个线程中访问其他线程的非静态局部变量。i)仅在循环体中执行线程的挂起操作，并在每次挂起线程之前检查线程继续执行要满足的条件。j)不要加入或分离已进行过加入或分

34、离操作的线程。k)谨慎处理原子变量。禁止在一个表达式中两次访问同一个原子变量。程序无法确保在两次访问该变量之间，其值不被其他线程修改。l)进行特权让渡时，应遵守正确的特权废除顺序，确保特权让渡过程成功。m)不要使用异步取消的线程，防止产生资源泄露。n)不要在条件变量同步等待操作中使用多于一个的互斥条件。o)释放互斥锁时，建议线程通知所有正在等待该锁的线程，而不是单一线程。p)在多线程环境下，应确保应用的不同会话之间不会发生信息泄露。相关的规范和不规范的代码示例参见附录 A.3.2。GB/T XXXXXXXXX116.3 函数调用安全应用软件应从如下方面保障函数调用安全，包括但不限于：a)函数应

35、对传入的参数进行合法性、安全性验证，包括但不限于对参数数量、顺序、类型、值的验证。b)函数应能正确并安全的处理传入参数的数量、顺序、类型、值不满足预期的情况。c)函数应谨慎处理来自不可信数据源的格式化字符串，避免直接用于构造命令。d)宜检查函数的返回值是否符合预期，避免忽略函数的返回值。e)避免在函数中返回栈变量地址。f)应避免在应用程序编程接口（API）或与外部交互的接口中暴露那些原本设计为仅限内部或部分用户访问的危险方法或函数，否则可能会导致非授权访问攻击。g)应避免使用在不同版本具有不一致实现的函数或方法。相关的规范和不规范的代码示例参见附录 A.3.3。6.4 异常处理安全应用软件应建

36、立完善的异常和错误处理机制，确保异常与错误可以被及时识别并处理。应从以下方面提升异常和错误处理的安全性，包括但不限于：a)软件应自行处理程序错误，并且不依赖于服务器配置。b)避免在越过执行边界时抛出异常。c)避免在静态对象的构造器和线程存储周期内抛出异常。d)异常处理时应保持数据的状态一致性。e)异常处理时应及时回收并释放系统资源。f)精确捕获异常，并对捕获的异常进行恰当的处理，避免在捕获异常后不做任何处理。g)不在软件执行异常时暴露敏感信息：向用户展示通用的错误提示信息。在系统发生异常状况时禁止向用户暴露的敏感信息包括但不限于：系统的详细信息、会话标识符、账号信息、调试或堆栈跟踪信息。相关的

37、规范和不规范的代码示例参见附录 A.3.4。6.5 指针安全程序的设计和开发有关指针的操作需从以下方面提升软件的安全性，包括但不限于：a)在使用指针的过程中，应确保指针的有效性。b)确保指针类型的正确使用：明确指针类型的兼容性。不应将非结构体类型指针强制转换为指向结构类型。c)确保正确地使用指针运算：不要在非数组对象的指针上执行指针运算。避免使用指针的加减法来确定内存大小。d)避免将固定地址赋值给指针。e)指针使用时应防止偏移越界。相关的规范和不规范的代码示例参见附录 A.3.5。6.6 代码生成安全程序的源代码编写完成后，在编译以及链接过程中，应当从以下几方面保证安全性，包括但不限于：GB/

38、T XXXXXXXXX12a)对编译所依赖的库的使用应当首先进行版本判断。b)对某些重要的库（比如加密、通信等）应当进行哈希校验。c)编译命令中的宏定义不能存在冲突。d)针对同一个工程的编译，Release/Debug 设置应当统一。e)不要通过 makefile 参数直接配置宏名，应当以可选的选项形式提供。f)不要通过编译参数配置软件的版本信息。g)引用头文件的路径不能直接开放。h)引用头文件的路径中，不能有存在歧义的头文件路径。i)同一个工程中，不同的编译过程如果使用了同一个库的不同版本，应当有明确的注释或提示说明。j)如果编译的源代码来自不同的代码仓库，应当配置统一的版本、分支控制脚本。

39、k)编译生成的结果文件（.o 文件、.obj 文件）应当保存在独立于源代码的路径中。l)谨慎使用编译过程中自动生成的源代码。7资源使用安全7.1 资源管理应用软件需对所使用的各种资源（如文件、数据库、网络）从以下方面进行安全管理，包括但不限于：a)确保系统中的每个资源具有唯一的标识符。b)使用重要资源前应进行正确初始化，并确保初始化失败后可以安全退出程序。c)正确的更新资源的引用计数。d)正确释放系统资源：及时释放系统资源。禁止再次释放已经释放的资源。释放资源前应完全清除敏感信息。确保应用软件在使用资源后恰当地执行临时文件或辅助资源的清理，避免清理环节不完整。e)不使用已过期或已释放的资源。f

40、)对分配的资源数量、使用权限、有效时间做限制，防止消耗过多资源。g)合理控制递归。h)执行迭代或循环应恰当地限制循环执行的次数，应避免无限循环。i)系统提供的资源池应能满足高峰期的业务需求。j)对外部资源，如下载的文件，应进行完整性和发布源检验，确保外部资源的安全性。相关的规范和不规范的代码示例参见附录 A.4.1。7.2 内存管理除了 7.1 规定的内容外，应用软件还应从以下方面提升内存管理安全性，包括但不限于：a)保持一致的内存管理约定：使用同样的模式分配和释放内存。在同一个模块中，在同一个抽象层次中，分配和释放内存。分配和释放必须配对。b)谨慎操作缓冲区：GB/T XXXXXXXXX13

41、缓冲区的读写操作时应进行边界检查，避免向指定的缓冲区外读取或者写入数据。对不可信数据进行输入和输出控制。字符串操作时，检查字符串长度和终止符，应保证字符串的存储具有足够的空间容纳字符数据和终止符。在循环中调用函数时，注意检查缓冲区空间大小，确保不存在超出分配空间的访问。不要在无关的智能指针中存储已有的指针值。c)避免对同一块内存释放两次。d)已释放的内存，在再次分配前禁止写入。e)及时释放内存，避免依赖垃圾回收机制。f)保护堆安全：执行堆完整性检测。在可能的情况下，使用不可执行的堆栈。限制堆空间的消耗，谨慎处理创建线程、解压文件、反序列化等消耗空间的操作，防止堆空间耗尽。g)应尽量避免使用不进

42、行自变量检查的、已知存在漏洞的字符串操作函数，如 printf、strcat、strcpy，并使用其他函数替代。h)尽量避免对过度整齐的数据类型使用默认操作。相关的规范和不规范的代码示例参见附录 A.4.2。7.3 数据库管理除了 7.1 规定的内容外，应用软件还应从以下方面提升数据库管理安全性，包括但不限于：a)当应用程序访问数据库时，禁止使用默认的角色、账户与默认数据库口令访问数据库。b)使用数据库进行数据存储时，应确保数据的完整性。c)使用参数化 SQL 语句，禁止改变数据定向的上下文环境，并强制区分数据和命令。d)使用存储过程以实现抽象访问数据，并允许对数据库中表的删除权限。e)当应用

43、程序访问数据库时，仅提供给应用程序满足其需求的最低权限，以降低访问数据库的风险。f)规定不同信任级别用户连接数据库的角色，比如用户、只读用户、访问用户、管理员。g)使用行级别的访问控制，禁止依赖应用程序访问控制来保护数据库的数据，限制每个请求使用户只能访问他们自己的数据。h)为所有变量指定数据类型，并在编译期间进行严格检查。i)对来自数据库的数据进行验证，确保从数据库读出的数据符合预期。j)及时释放数据库资源，例如连接、游标等。k)关闭所有不必要的数据库功能，如不必要的存储过程或服务、应用程序包，最小化需安装的功能和选项。相关的规范和不规范的代码示例参见附录 A.4.3。7.4 文件管理除了

44、7.1 规定的内容外，应用软件还应从以下方面提升文件管理安全性，包括但不限于：GB/T XXXXXXXXX14a)采用最小权限原则进行文件访问授权。b)对来自文件系统的所有信息（包括但不限于文件路径、文件名的内容和长度）进行标准化，然后进行验证。c)确保文件上传安全：上传文档前进行身份鉴别。验证文件类型，仅允许上传满足业务需要的相关文件类型。除验证文件类型扩展名外，还需至少检查文件报头中的类型信息。访问上传的文件之前，进行恶意代码的扫描，并校验文件完整性。关闭在文件上传目录的运行权限。d)禁止传递目录或绝对文件路径给用户，建议使用预先设置的路径列表中的匹配索引值。e)使用安全的临时文件：建议在

45、程序初始化时采用严格的权限策略建立安全的临时文件夹，存放可能产生的临时文件，并且只对该应用程序开放访问权限。最小化临时文件存储时间，并及时删除临时文件。f)禁止用户修改应用程序文件和资源，权限仅限于可读。g)避免文件访问竞争，使用文件句柄来保证针对某文件的多次操作确实是对同一个文件的操作。h)确保及时释放文件系统资源：保证诸如文件句柄之类的文件系统访问结构在不再需要时会被及时释放。禁止依赖 Java 和.NET 等的垃圾回收机制来回收资源。i)检测和处理文件相关的错误。比如，Java 文件操作往往通过返回值来表示操作是否失败，Java 程序必须检查 I/O 方法的返回值。j)禁止使用过期的文件

46、句柄。k)在调用子进程之前应关闭敏感文件句柄，避免子进程使用这些句柄来执行未授权的I/O 操作。相关的规范和不规范的代码示例参见附录 A.4.4。7.5 网络传输除了 7.1 规定的内容外，应用软件还应从以下方面提升网络传输安全性，包括但不限于：a)验证通信通道源，确保数据来自预期源。b)对来自网络的数据进行验证以确保数据包符合预期要求。c)使用加密传输确保通信安全：应采用加密传输方式保护敏感数据，特别是要求身份鉴别的数据内容、与外部系统交换的数据内容等。宜使用配置合理的单一标准 TLS 或 SSL 对连接保护，并支持对敏感文件或非基于 HTTP 连接的不连续加密。没有成功的 TLS 连接不应

47、当后退成为一个不安全的连接。为在 TLS 连接上传输的 cookie 设置“安全”属性。TLS 证书应当是有效的，有正确且未过期的域名，并且在需要时，和中间证书一起安装。d)应对信道中传输的消息进行完整性验证。e)应当使用时间戳和随机数组合的方式进行重放检测。f)至少从以下方面管理会话安全：GB/T XXXXXXXXX15使用服务器或者框架的会话管理控制。应用程序应当只识别有效的会话标识符。会话标识符必须总是在一个可信系统上创建。确保会话标识符的随机性。建议用账户登出后应完全终止相关的会话或连接。在平衡风险和业务功能需求的基础上，最小化会话超时时间（通常小于几个小时）。如果一个会话在登录以前就

48、建立，在成功登录以后，应关闭该会话并创建一个新的会话。任何重新进行身份鉴别的过程,都应建立一个新的会话标识符。不允许同一用户 ID 的并发登录。在身份鉴别的时候，如果连接从 HTTP 变为 HTTPS，则生成一个新的会话标识符。在应用程序中，宜持续使用 HTTPS，而非在 HTTP 和 HTTPS 之间转换。为服务器端的操作执行标准的会话管理，比如，通过在每个会话中使用强随机令牌或参数来管理账户。g)应避免将多个套接字绑定到相同端口，从而导致该端口上的服务有被盗或被欺骗的风险。h)提供跟踪网络传输流量的机制，控制网络传输流量不超过被允许的值。相关的规范和不规范的代码示例参见附录 A.4.5。8

49、环境安全8.1 第三方软件使用安全在应用软件的构建、运行等环节，可从如下方面提升应用软件所使用的第三方软件的安全性，包括但不限于：a)搭建并维护统一的第三方软件仓库，应当仅能从内部搭建的组件仓库获取第三方软件，不允许自行下载组件进行使用。b)从官方渠道获取第三方软件，并确保所有组件都及时升级到不存在已知高危漏洞的版本。c)对第三方软件进行完整性验证测试，确保所用第三方软件未被篡改。d)定期对第三方软件进行安全性检测，避免使用已知存在高危漏洞的组件版本。e)确保第三方软件许可证的真实有效性，避免使用存在许可证冲突的组件。f)建议使用软件成分分析工具和漏洞检测工具，及时识别并规避存在安全风险的第三

50、方组件。g)在采用容器作为运行环境的场景中，也应当确保容器中所使用第三方软件的安全性。h)建议使用经国家权威第三方安全检测机构检测认证的第三方软件进行应用软件开发。相关的规范和不规范的代码示例参见附录 A.5.1。8.2 开发环境安全开发者应从以下方面保障软件开发环境的安全，包括但不限于：a)构建安全的编译环境：从官方渠道获取编译器，并确保安装了所有补丁。去掉不必要的编译功能，如去掉调试开关。如果编译器提供了安全编译选项，应当正确配置并使用。GB/T XXXXXXXXX16b)合理存储源代码，制定权限控制策略，保护源代码不被非法用户访问。c)建议使用软件变更管理系统以管理和记录在开发和产品迭代