应用软件开发安全

数据访问范围的权限设计
应用功能模块使用权限的设计
9
访问控制和授权
限制用户的权限：
限制用户对系统级资源的访问，包括文件、文件夹、注册表项、LDAP 对象、数据库对象、日志文件等；
应用系统使用的数据库帐号必须是普通权限帐号，只能访问允许的数据库；
应用系统启动进程的权限尽可能小；
合理设计用户权限的颗粒度，满足授权最小原则。
记录详细的错误信息：向错误事件日志发送详细的错误消息，同时确保没有记录密码或其他敏感数据。
开发阶段
规范
建议
1
应用开发环境的安全要求
开发环境应划定专门的安全区域，如非必需，禁止或限制与生产网和互联网的互联。
存储项目文档、代码的服务器必须有严格的访问控制管理、备份制度。
对项目文档和代码的访问应严格受控。
不要在代码中包含敏感信息：不要在代码中对敏感信息进行硬编码，例如 IP 地址、口令等。即使源代码不会泄漏，但从编译过的可执行文件中仍然可以提取字符串常量。配置漏洞可能会允许攻击者检索可执行文件，从而获取敏感信息。
不要以明文形式存储数据库连接字符串或密码等敏感信息，应该进行加密，并存储经过加密的字符串。
3
应用系统应该考虑到数据安全和冗余恢复相关功能需求。
4
应用系统应该包含安全日志审计功能，并明确对于日志内容的要求。
应用系统审计的事件应该包括但不限于以下类型：
审计功能的启动和关闭
修改审计功能的配置
登录和退出的时间
各种违例行为
对重要数据的变更操作
对应用系统的维护操作，包括参数修改
日志应该至少记录以下信息：
16
敏感数据的保护
处理诸如信用卡卡号、持卡人个人信息、账户信息、密码、证书等敏感信息的应用程序应该采取专门的处理流程，以确保这些数据的保密性和完整性，包括使用足够强度的加密算法保护其保密性和使用哈希算法进行完整性校验。
尽量避免存储机密信息：存储在系统中的机密信息即使经过加密也无法保证完全安全，可以接触到服务器的系统管理员就可以访问这些数据。替代的方法可以用哈希值比对的方式。
4
身份识别和认证
帐号的管理
帐号生命周期管理：帐号的生成、变更、挂起和删除等建议由集中的身份管理平台完成。如果在应用系统内部实现账号生命周期管理，要充分考虑各个阶段对安全的要求。
帐号存储模式：应用系统的帐号要求使用支持 LDAP 目录的存储方式。如果应用系统因为某种原因不能使用企业级 LDAP 目录存储帐号（或者企业级 LDAP 尚未建立），对于同一类型的应用，要尽量使用同一个 LDAP 目录存储帐号信息，这一目录要求定期与企业级LDAP 目录进行同步。
对项目文档和代码要采取版本管理和控制。
开发终端的安全要求至少要和办公用终端有同样的安全要求。
2
应用开发文档的安全要求
开发各阶段输出的文档应有相应的安全方面的内容。
需求说明书中应明确描述用户的安全需求。
设计中应有针对安全需求的设计，并需要经过评审。
在测试计划或者测试方案中应有安全性测试方案，并据此进行安全性测试，保留测试记录。
系统测试和验收测试通常需要尽可能接近实际运行数据的测试数据，应避免使用含有个人信息的业务数据库。如果要使用其中信息，必须在使用之前使其失去个性化。当把运行数据用于测试目的时，应采取措施保护运行数据。
在与其他系统的交互性测试中，应充分考虑对其他系统的影响，选择适当的时间、方法。
测试完成后上线前应进行安全核查，消除测试用的后门、用户名及口令等。
不在网络上以明文方式传输密码：以明文方式在网络上传输的密码容易被窃听，为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。
保护身份认证的凭据：身份认证的凭据（如 Cookie）被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护认证的凭据。此外，还应限制认证凭据的有效期，以减少攻击的威胁。
应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。
应对原始数据需要进行检错和校验操作，保证原始数据的正确性和完整性。
数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格式要求。
数据处理过程应保留处理数据的状态信息（日志）。
应明确测试使用的方式，主要的测试方式有功能测试、压力测试和渗透性测试。
应明确测试的安全要点、测试参与人员、测试流程，并编写测试计划。
应根据测试计划制定测试方案，明确测试的各项要求和测试用例。
测试环境的硬件、软件环境和基础架构应模拟真实环境。
测试数据尽量避免采用真实数据，如果必须使用，应限定测试的人员，并在测试完成后全部删除。
如果通过网络传输敏感数据，禁止明文传输，应对数据进行加密。同时确保通信通道的安全，通常的做法是使用SSL/TLS、HTTPS、SFTP 和 IPSec 等安全协议进行通信。
16
异常处理
不要向客户端泄漏应用程序内部信息：发生故障时，不要在出错消息中暴露应用系统内部的敏感信息。例如，不要暴露包括函数名以及调试信息（出问题的行数，堆栈信息等）。应向客户端返回一般性错误消息。
6
应用系统上线投产的安全要求
规划应用系统上线所需要的资源需求和准备工作，包括但不限于以下内容：
应用系统上线对软件、硬件资源和网络的要求。
应用系统上线对相关部门、人员的要求。应明确所有参与人员的职责，要求签字确认。
应用系统上线的时间进度安排。
其它资源的详细清单。
应将应用系统的上线方案提交给相关部门主管，只有批准方可进行。
输入标准化：标准化是指将输入数据转化为标准形式的过程。在接受文件名输入、URL 或用户名输入时必须先进行标准化。
限制、拒绝和净化输入：输入验证的首选方法是从一开始就限制
允许输入的内容，并按照已知的有效类型、模式和范围验证数据。
清晰定义数据输入处理流程中涉及人员的责任。
12
数据处理控制
要有措施保证应用程序按照正确的运行次序执行，如果出错就中断执行，后续处理过程将暂停运行直到错误排除，防止在前一流程出错的基础上继续运行。
10
输入数据验证
采用输入复核或其他输入检查方式，例如边界检查、限制数据输入字
段的范围和类型等，检验是否有以下输入错误：
输入过长
输入数据字段中有非法字符
输入为空或者不完整
输入值超过上限或下限
11
输入数据验证
在服务器端进行验证：应使用服务器端代码执行其数据的输入验证。如果使用客户端验证方式，有可能发生攻击者绕过客户端验证或关闭客户端验证脚本进程的情况。
确保测试环境的安全。应将测试环境与开发环境、生产环境相隔离，避免测试工作对业务的影响。
应详细记录测试过程发生的各个事件，列出测试过程中发现的问题。这些信息包括：发现了什么，在哪里发现的，当时的环境，这些问果，提出被测试系统、测试过程等方面的改进说明。
应确保测试用例、测试内容和测试结果的保密性。
应用软件开发安全规范
需求阶段
规范
建议
1
应用系统应该包含身份认证功能，或者使用外部的集中身份认证系统的要求，并且明确对用户身份认证体系强度的要求，以及认证失败后的处理方式。
2
应用系统应该包含用户权限分配和管理功能，应该根据系统所处理的业务数据的保密性、完整性要求，确定系统用户权限访问控制模型和权限的颗粒度要求，同时体现职责分离的原则。
数据处理过程应具备异常处理功能，在任一环节发现问题，均能及时回退，必要时可以人工处理。
13
数据输出验证
验证输出的数据是否准确、合理。
要保证所有的数据都被处理了。
数据输出验证过程应保留验证过程的相关信息（日志）。
14
配置管理
应用系统配置管理安全设计要求：
应用系统配置管理功能只能由经过授权的操作员和管理员进行，建议使用强身份认证手段，如使用双因素认证。避免使用远程配置管理。
防止程序员非授权修改代码禁止在程序中添加隐藏“恶意”的代码，防止与应用系统相关的程序员对系统的非授权修改。
4
应用开发的代码安全要求
规范代码的格式：
规范变量、函数的命名
规范程序的书写格式，确保程序的易读性
5
应用系统的安全测试：
应用系统的安全性测试包括以下内容：
测试前应明确测试目的，帮助所有测试人员熟悉测试的目的和意图。
所有缺省安全设置必须能同时满足系统正常运行和系统安全两方面的要求。
在所有警告或提示对话窗口中所使用准确、明了的描述性语言，并提供有关帮助链接。
在接受用户输入时，必须有数据合法性检查，并严格规定输入数据的字符长度。
隐藏所有敏感的信息。
在输入密码等敏感信息时，使用星号来代替输入的字符。
在设计基于Web 的软件时，必须确保当用户注销会话进程后，包含敏感信息的页面不能通过使用浏览器的回退（Back）按钮来显示。
事件的发起源
用户标识（终端用户实体或系统内部调用用户）
事件类型
事件的日期和时间
事件的结果：成功或失败
受影响的数据或资源
5
明确应用系统所处理的业务数据范围和内容，针对不同安全级别的数据在应用系统不同处理过程中对机密性、完整性和可用性的要求，定义其对安全保护的具体需求。
6
针对不同数据对安全保护的要求，评估应用系统相关的硬件平台、操作系统、基础架构、网络通信、中间件和服务是否能够满足要求。
7
访问控制和授权
应用系统的认证、授权尽量使用统一的认证、授权平台来进行。如果因为某种原因需要建立应用系统自己的认证、授权体系，整个认证过程需要进行加密，密钥长度不能低于 128 位。
8
访问控制和授权
应用系统的设计应包含用户权限分配和管理功能：
系统读、写、执行权限设计
系统查看、配置、修改、删除、登录、运行等权限设计