100字范文 > 应用软件安全编程概述

应用软件安全编程概述

时间：2023-10-31 04:17:51

相关推荐

应用软件安全编程概述

声明

本文是学习GB-T 38674- 信息安全技术应用软件安全编程指南. 下载地址 /view/624而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们

应用软件安全编程概述

本指南从程序安全和环境安全两个方面提出了提升应用软件安全性的编程最佳实践。其中，程序安全部分描述软件在资源使用、代码实现、安全功能方面的安全技术规范，环境安全部分描述软件的安全管理配置规范。图1为本标准描述的应用软件编程安全框架。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lD32NTaO-1673234202496)(null)]图1应用软件编程安全框架

应用软件安全编程安全功能实现

数据清洗

输入验证

应用软件应确保对所有输入到应用的数据进行验证，拒绝接受验证失败的数据。在设计和实现数据验证功能时需关注以下方面内容，包括但不限于：

验证所有输入数据的安全性，包括但不限于以下方面的验证：检测输入数据的数据类型。检测输入数据的长度，验证允许输入的最小和最大长度。检测输入数据的值，包括进行最小值、最大值边界值检查。参考7.4©验证文件的安全性。应特别关注如下场景的数据验证：验证来自HTTP请求中的所有数据，恶意数据可以从表单域，URL参数，cookie，HTTP头以及URL自身传入。验证来自重定向输入的数据。攻击者可能向重定向的目标直接提交恶意代码，从而避开应用程序逻辑以及在重定向前执行的验证，所以对重定向输入数据应再次验证。对来自命令行、环境以及配置文件的输入进行校验。对发送给文件系统、浏览器、数据库或者其他系统的命令进行验证，防止采用不可信来源的数据构建命令。对重要业务操作相关的输入数据，应验证数据的真实性和完整性，宜验证数据发送方的数字签名，以确认数据发送方的身份。对输入的数据进行过滤或标准化处理，然后进行验证。禁止试图对验证失败的数据进行修复，自动错误恢复代码很可能改变请求的初始意图或者截断验证逻辑。在可信任环境中执行输入验证。集中输入验证，把输入验证作为软件框架的一部分，为应用程序提供一个统一的输入验证策略。为所有输入明确恰当的字符集，比如：UTF-8。确定系统是否支持UTF-8扩展字符集，如果支持，在UTF-8解码完成以后进行输入验证。在程序中定义清晰的信任边界，将可信和不可信数据（比如：数据库，文件流）分别存储。当数据要从不可信的一侧传输到可信一侧的时候，应使用验证逻辑进行判断。

相关的规范和不规范的代码示例参见附录A.2.1.1。

输出净化

应用软件应对所有输出到客户端的，来自于应用程序信任边界之外的数据进行净化。应用软件在设计和实现输出净化功能时需关注以下方面内容，包括但不限于：

除非明确对目标编译器是安全的，否则对所有字符进行编码。在可信任环境中执行输出编码。应以国际、国家、行业标准为基础，结合实际情况制定编码规则。关注SQL、XML和LDAP查询语句以及操作系统命令，这些命令可能存在潜在的危险字符，应语义净化。应禁止将URL重定向到用户可控的不可信站点。

相关的规范和不规范的代码示例参见附录A.2.1.2。

数据加密与保护

加密规范

应用软件应对敏感数据进行加密保护，数据加密的设计和实现需关注以下方面内容，包括但不限于：

凡涉及采用密码技术解决保密性、完整性、真实性、不可否认性需求的，须遵循国家有关法律法规。即使在服务器端，仍然要加密存储敏感数据。在可信任环境中执行数据的加密过程。确保密码运算过程安全。应基于指定的算法和特定长度的密钥来进行密码运算。安全地处理加密模块的失败操作。如果加密模块加密失败或报错，需重新加密。应当按照用途尽量减少需要保存的秘密信息。建立并使用相关的安全策略和流程以实现加、解密的密钥管理。使用安全的随机数生成器：应采用能产生充分信息熵的算法或方案。避免将具有密码学弱点的伪随机数生成器（PRNG）用于加密场景。使用密码学的伪随机数生成器时，应使用信息熵最大的信息作为密码学伪随机数生成器的种子。如果信息熵不可用，可使用变化的种子来降低安全威胁，但应避免使用可预测的种子（如进程ID或系统时间的当前值）、或空间太小的种子。维护密钥的安全：应规定安全的密钥强度，仅使用高于规定强度的密钥。应规定密钥有效期，禁止使用已经过期的密钥。禁止使用硬编码密钥，硬编码密钥将显著增加加密数据被攻击者破解的可能性。

相关的规范和不规范的代码示例参见附录A.2.2.1。

数据保护

应用软件应从以下方面保护数据的安全，包括但不限于：

应明确应用软件中的敏感数据、隐私数据的范围，以及有权访问这些数据的用户范围。在软件中明确划定信任边界，禁止敏感数据跨越信任边界。对数据的授权访问遵循最小权限原则。应参照5.2.1节的内容对敏感数据进行加密存储和传输。对重要数据进行完整性检查。尽量缩短敏感数据的存储时间，并减少敏感数据的存储地点，以降低敏感数据泄露的风险。避免在错误消息、进程信息、调试信息、日志文件、源代码或注释中包含敏感数据。在设计WEB登录表单的时候，可考虑禁止浏览器的口令自动填充功能。资源释放前应清理敏感数据。保护所有在服务器上缓存的或临时拷贝的敏感数据，并在不需要时尽快清除。禁止在客户端保存敏感数据。当敏感数据丢失或破坏时，确保可通过备份数据进行数据恢复。在将数据发送到客户端的时候，应基于任何通过客户端共享的数据都是不安全的假设对数据进行操作。

相关的规范和不规范的代码示例参见附录A.2.2.2。

访问控制

身份鉴别

身份鉴别的设计和实现应注意以下方面内容，包括但不限于：

建立并使用标准的、已通过测试的身份鉴别策略，如可参照《ISO/IEC 9798-1:信息技术安全技术实体鉴别第1部分：总则》中的要求设计和实现身份鉴别策略。根据业务安全要求选择身份鉴别方式，安全性要求高的系统建议采用多因素身份鉴别方式。为所有身份鉴别使用一个集中实现的方法，包括利用库文件请求外部身份鉴别服务。所有的身份鉴别过程必须在可信任环境中执行，且在每次用户登录时进行身份鉴别。避免仅在客户端而非服务器端执行身份鉴别。最小化角色授权，一个账号对应一个人而不是一个组，使用软件的每个人应拥有唯一的用户名。避免依赖不可靠信息进行身份鉴别。在进行关键的安全操作时：不应信任cookie中的数据。不应依赖反向DNS解析获取的主机信息。验证数字证书。必须检查证书的状态和证书持有者，只有有效的、未过期的且证书的实际持有者与证书中声明的持有者一致的证书才能被信任和使用。避免鉴别过程被绕过：严格控制用户访问系统的可选途径或通道，保证用户只能通过指定的途径或通道访问系统，避免身份鉴别被绕过。应使用安全的鉴别算法，且算法的关键步骤没有被省略或跳过。避免在处理身份鉴别的过程中透露多余信息：处理每个认证请求所花费的时间相同。避免攻击者根据登录尝试失败的时间来判断登录尝试是否成功。安全地处理未成功的认证。认证和注册的错误信息不能包含可被攻击者利用的信息，例如，判断一个特定的用户名是否有效的信息。确保鉴别反馈的内容中不包含敏感数据。对鉴别尝试的频率进行限制，连续多次登录失败强制锁定账户：限制同一个账号能够进行鉴别尝试的频率和次数。应设定用户登录失败次数的阈值，在用户登录失败次数达到阈值后应锁定用户账号，防止攻击者进行暴力破解。如果允许一次身份鉴别后，可进行较长时间的通话，则应周期性地重新鉴别用户的身份，以确保其权限没有改变。如果发生改变，注销该用户，并强制重新执行身份鉴别。在用户执行关键或者不可逆的操作（如修改口令）之前，再次鉴别用户身份，以减少不安全会话带来的损失。避免使用过于严格的账户锁定机制（账户锁定保护机制过于严格且容易被触发，就允许攻击者通过锁定合法用户的账户来拒绝服务合法的系统用户）。实现用户与主体的绑定：用户进程应与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。系统进程应与当前服务要求者用户动态关联，使系统进程的行为可以追溯到当前服务要求者用户。

相关的规范和不规范的代码示例参见附录A.2.3.1。

口令安全

应用软件需从以下方面保护口令的安全，包括但不限于：

登录过程中，应确保口令不可见。使用强口令，口令的复杂度（包括口令组成、口令长度等）应满足安全策略要求。禁止使用弱口令、空口令或已泄露的口令。对于默认的初始口令，强制用户初次登录时更改默认口令。不使用过期口令：过期口令不可继续使用。应定期更改口令，关键系统可要求更频繁地更改。应明确口令更改时间周期。保护口令重置信息：应使用保护口令信息的安全策略保护口令重置信息。口令重置操作应采取与账户创建、身份鉴别同等级别的安全控制策略。口令重置问题应当支持尽可能随机的提问。安全地存储口令：禁止明文存储口令。应使用不可逆的加密算法或单向杂凑函数对口令进行加密存储。在散列过程加入盐，将口令转化为不可还原或难以使用字典攻击猜测的形式。应将加密后的口令存储在配置文件、数据库或者其它外部数据源中。禁止在源代码中写入口令。所有的口令加密过程必须在可信任环境中执行。尽可能地减少口令、加密密钥的保存时间。使用安全的口令传输：禁止在不安全的信道中传输口令，也禁止接受来自不安全信道的口令。禁止传递明文口令。传统协议，如FTP，TELNET，HTTP，POP以及IMAP，应在使用了安全传输协议（例如SSL）的情况下才可被用于传输口令。用户信息改变时使用单独的信道通知：允许用户改变其口令，当用户改变其账号信息时（例如重置口令）需要发送确认信息，确认信息应使用单独的通道发送。可要求用户通过邮件等方式来确认信息的变更，但禁止在确认邮件中包含身份鉴别信息。当用户改变他们的联系信息时，应发送两次变更通知：分别包含旧的和新的信息。

相关的规范和不规范的代码示例参见附录A.2.3.2。

权限管理

应用软件对于权限管理的设计和实现应关注以下方面内容，包括但不限于：

遵循最小权限原则：服务账户或连接到外部系统的账号，应当具有执行经授权的任务所需的最小权限（或最低的安全许可）。将许可权限尽可能地细化，使用细粒度的访问控制。所有的访问授权操作需在可信任环境中执行。将访问控制作为集中化程序框架的一部分，建立统一的访问控制策略。对每个用户交互都要检测访问控制状态。确保访问控制策略检查了用户访问或操作的数据。只有授权的用户才能访问秘密数据或敏感数据。通常，这些数据包括但不限于：与用户信息或应用软件自身安全密切相关的状态信息、文件或其他资源、受保护的URL、受保护的功能、直接对象引用、应用程序数据以及与安全相关的配置信息。执行账户审计并强制失效长期不使用的账户。建议明确允许账户不使用的最长期限，支持账户的强制失效，并在账户停止时终止会话。

相关的规范和不规范的代码示例参见附录A.2.3.3。

日志安全

应用软件日志记录了系统运行状况，通常包括但不限于软硬件故障、系统重要事件等。日志记录的设计和实现需从以下方面提升安全性，包括但不限于：

保护日志文件：应对日志文件进行安全存储，例如将日志文件独立保存于应用程序目录外，使用严格的访问权限来控制日志文件使用。使用消息摘要算法以验证日志记录的完整性。在可信任的环境中执行日志记录操作。将日志记录作为集中化程序框架的一部分。在每个日志条目中增加精确的时间戳，同时确保时间戳的可靠性。对每个重要的行为都记录日志：确保系统在发生重要安全事件时创建日志。重要安全事件通常包括但不限于：重要数据更改、认证尝试（特别是失败的认证）、失败的访问控制、失效或者已过期的会话令牌尝试、系统例外、管理功能行为、失败的后端TLS链接、加密模块的错误。对日志记录进行完善的异常捕获处理，确保即使日志记录过程发生异常，日志记录仍然能够继续正确的执行。应对日志中的特殊元素进行过滤和验证。确保日志记录中的不可信数据，不会在查看界面或者运行软件时以代码的形式被执行。采取安全措施防止攻击者写任意的数据到日志中。避免在日志中保存敏感数据。

相关的规范和不规范的代码示例参见附录A.2.4。