应用软件开发安全.doc

(完整word)应用软件开发安全
应用软件开发安全规范

需求阶段
规范
建议
1
应用系统应该包含身份认证功能，或者使用外部的集中身份认证系统的要求,并且明确对用户身份认证体系强度的要求,以及认证失败后的处理方式。
2
应用系统应该包含用户权限分配和管理功能，应该根据系统所处理的业务数据的保密性、完整性要求，确定系统用户权限访问控制模型和权限的颗粒度要求，同时体现职责分离的原则。
3
应用系统应该考虑到数据安全和冗余恢复相关功能需求。
4
应用系统应该包含安全日志审计功能，并明确对于日志内容的要求.
应用系统审计的事件应该包括但不限于以下类型：
l 审计功能的启动和关闭
l 修改审计功能的配置
l 登录和退出的时间
l 各种违例行为
l 对重要数据的变更操作
l 对应用系统的维护操作，包括参数修改
日志应该至少记录以下信息：
l 事件的发起源
l 用户标识（终端用户实体或系统内部调用用户）
l 事件类型
l 事件的日期和时间
l 事件的结果：成功或失败
l 受影响的数据或资源
5
明确应用系统所处理的业务数据范围和内容,针对不同安全级别的数据在应用系统不同处理过程中对机密性、完整性和可用性的要求，定义其对安全保护的具体需求.
6
针对不同数据对安全保护的要求，评估应用系统相关的硬件平台、操作系统、基础架构、网络通信、中间件和服务是否能够满足要求。
7
针对应用中对数据处理的整个过程，明确其对监控和检查的要求，包括日志审计、完整性检查、出错检查等.

设计阶段
规范
建议
1
为了保证应用系统的安全性,外部系统的安全应当包括如下几个方面：
l 应用系统服务器硬件物理安全
l 应用系统服务器操作系统安全
l 应用系统数据库的安全
l 应用系统的存储安全
l 应用系统用户终端安全
l 应用系统网络通信安全
2
身份识别和认证
不同安全级别的系统对用户身份识别和认证体系的强度要求也不同， 按照强度由低到高分别有以下几种方式：
l 用户名、口令认证
l 一次性口令、动态口令认证
l 证书认证
l 生物特征的认证（指纹、掌纹、视网膜等)
3
身份识别和认证
认证失败后的处理方式:
l 连续失败的登录尝试后锁定帐号，并把事件内容记录到审计日志中.
l 以电子邮件或短信等方式通知用户认证失败。
4
身份识别和认证
帐号的管理
l 帐号生命周期管理：帐号的生成、变更、挂起和删除等建议由集中的身份管理平台完成。如果在应用系统内部实现账号生命周期管理,要充分考虑各个阶段对安全的要求。
l 帐号存储模式:应用系统的帐号要求使用支持 LDAP 目录的存储方式.如果应用系统因为某种原因不能使用企业级 LDAP 目录存储帐号（或者企业级 LDAP 尚未建立），对于同一类型的应用，要尽量使用同一个 LDAP 目录存储帐号信息，这一目录要求定期与企业级LDAP 目录进行同步。
l 帐号的命名规范：应用系统的帐号命名规则和结构要符合企业统一的帐号命名规范和结构定义.
5
身份识别和认证
应用系统的口令规则需要符合企业统一的账号口令管理规范的要求。
6
身份识别和认证
对密码本身的保护：
l 避免存储实际密码：验证密码可以通过存储密码的单向哈希值,然后使用用户所提交的密码重新计算哈希值进行比对来实现。
l 不在网络上以明文方式传输密码:以明文方式在网络上传输的密码容易被窃听，为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。
l 保护身份认证的凭据：身份认证的凭据（如 Cookie）被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护认证的凭据。此外，还应限制认证凭据的有效期,以减少攻击的威胁.
7
访问控制和授权
应用系统的认证、授权尽量使用统一的认证、授权平台来进行。如果因为某种原因需要建立应用系统自己的认证、授权体系,整个认证过程需要进行加密，密钥长度不能低于 128 位。
8
访问控制和授权
应用系统的设计应包含用户权限分配和管理功能：
l 系统读、写、执行权限设计
l 系统查看、配置、修改、删除、登录、运行等权限设计
l 数据访问范围的权限设计
l 应用功能模块使用权限的设计
9
访问控制和授权
限制用户的权限：
l 限制用户对系统级资源的访问，包括文件、文件夹、注册表项、LDAP 对象、数据库对象、日志文件等；
l 应用系统使用的数据库帐号必须是普通权限帐号，只能访问允许的数据库;
l 应用系统启动进程的权限尽可能小；
l 合理设计用户权限的颗粒度，满足授权最小原则.
10
输入数据验证
采用输入复核或其他输入检查方式，例如边界检查、限制数据输入字
段的范围和类型等，检验是否有以下输入错误：
l 输入过长
l 输入数据字段中有非法字符
l 输入为空或者不完整
l 输入值超过上限或下限
11
输入数据验证
l 在服务器端进行验证：应使用服务器端代码执行其数据的输入验证。如果使用客户端验证方式,有可能发生攻击者绕过客户端验证或关闭客户端验证脚本进程的情况。
l 输入标准化：标准化是指将输入数据转化为标准形式的过程。在接受文件名输入、URL 或用户名输入时必须先进行标准化.
l 限制、拒绝和净化输入:输入验证的首选方法是从一开始就限制
l 允许输入的内容,并按照已知的有效类型、模式和范围验证数据.
l 清晰定义数据输入处理流程中涉及人员的责任。
12
数据处理控制
l 要有措施保证应用程序按照正确的运行次序执行，如果出错就中断执行,后续处理过程将暂停运行直到错误排除，防止在前一流程出错的基础上继续运行。
l 应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。
l 应对原始数据需要进行检错和校验操作，保证原始数据的正确性和完整性。
l 数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格式要求.
l 数据处理过程应保留处理数据的状态信息（日志）。
l 数据处理过程应具备异常处理功能，在任一环节发现问题，均能及时回退，必要时可以人工处理。
13
数据输出验证
l 验证输出的数据是否准确、合理。
l 要保证所有的数据都被处理了。
l 数据输出验证过程应保留验证过程的相关信息（日志）.
14
配置管理
应用系统配置管理安全设计要求：
l 应用系统配置管理功能只能由经过授权的操作员和管理员进行，建议使用强身份认证手段，如使用双因素认证。避免使用远程配置管理。
l 建议使用基于角色的授权策略分别为操作员、管理员授权。
l 针对进程帐号、服务帐号等系统内部帐号，其权限配置应遵循权限最小原则
15
配置管理
确保配置信息本身的安全:
基于文本的配置文件、注册表和数据库是存储应用程序配置信息的常用方法。应避免在应用程序的Web空间使用配置文件，以防止可能出现的因服务器漏洞而导致配置文件被下载或篡改.应避免以明文形式存储加密配置信息，如数据库连接字符串或认证凭据，应该通过加密确保这些信息的安全。同时必须限制对包含加密数据的注册表项、文件或表的访问权限。
16
敏感数据的保护
l 处理诸如信用卡卡号、持卡人个人信息、账户信息、密码、证书等敏感信息的应用程序应该采取专门的处理流程，以确保这些数据的保密性和完整性,包括使用足够强度的加密算法保护其保密性和使用哈希算法进行完整性校验.
l 尽量避免存储机密信息：存储在系统中的机密信息即使经过加密也无法保证完全安全，可以接触到服务器的系统管理员就可以访问这些数据。替代的方法可以用哈希值比对的方式.
l 不要在代码中包含敏感信息：不要在代码中对敏感信息进行硬编码，例如 IP 地址、口令等.即使源代码不会泄漏，但从编译过的可执行文件中仍然可以提取字符串常量。配置漏洞可能会允许攻击者检索可执行文件，从而获取敏感信息。
l 不要以明文形式存储数据库连接字符串或密码等敏感信息，应该进行加密，并存储经过加密的字符串。
l 如果通过网络传输敏感数据,禁止明文传输,应对数据进行加密。同时确保通信通道的安全，通常的做法是使用SSL/TLS、HTTPS、SFTP 和 IPSec 等安全协议进行通信.
16
异常处理
l 不要向客户端泄漏应用程序内部信息:发生故障时，不要在出错消息中暴露应用系统内部的敏感信息。例如,不要暴露包括函数名以及调试信息（出问题的行数，堆栈信息等）。应向客户端返回一般性错误消息。
l 记录详细的错误信息：向错误事件日志发送详细的错误消息，同时确保没有记录密码或其他敏感数据。

开发阶段
规范
建议
1
应用开发环境的安全要求
l 开发环境应划定专门的安全区域，如非必需，禁止或限制与生产网和互联网的互联.
l 存储项目文档、代码的服务器必须有严格的访问控制管理、备份制度.
l 对项目文档和代码的访问应严格受控。
l 对项目文档和代码要采取版本管理和控制。
l 开发终端的安全要求至少要和办公用终端有同样的安全要求。
2
应用开发文档的安全要求
l 开发各阶段输出的文档应有相应的安全方面的内容。
l 需求说明书中应明确描述用户的安全需求。
l 设计中应有针对安全需求的设计，并需要经过评审。
l 在测试计划或者测试方案中应有安全性测试方案,并据此进行安全性测试，保留测试记录。
l 文档应参照安全分类要求设定安全级别，读者范围，并有相应的授权机制,以控制对文档访问。
l 文档作为应用软件开发中的配置项,应遵循软件配置管理要求。
l 文档应有专用的服务器(或文件柜)进行保存和备份（复制),对于电子文档应有版本控制。
3
应用开发的代码安全要求
l 应对函数入口参数的合法性和准确性进行检查.
l 代码设计尽量简单清晰,如果设计过于复杂，就会给相应的安全设计带来很大的难度，而最终导致安全性的下降。
l 必须严格遵循 Fail—Safe 原则，即当发生问题时，必须能自动切换到最安全的保护模式。举例来说,当软件的登录验证机制不可正常运作时,软件必须自动拒绝所有登录请求,而不是接受所有登录请求。
l 禁止开发人员为普通的软件进程分配系统特权帐号软件(例如系统管理员、root 等）。
l 禁止接受不满足安全标准的登录密码。
l 所有缺省安全设置必须能同时满足系统正常运行和系统安全两方面的要求。
l 在所有警告或提示对话窗口中所使用准确、明了的描述性语言,并提供有关帮助链接。
l 在接受用户输入时,必须有数据合法性检查，并严格规定输入数据的字符长度。
l 隐藏所有敏感的信息。
l 在输入密码等敏感信息时，使用星号来代替输入的字符。
l 在设计基于Web 的软件时，必须确保当用户注销会话进程后，包含敏感信息的页面不能通过使用浏览器的回退（Back）按钮来显示.
l 禁止使用未经授权和验证的代码。
l 如果密码由软件生成，则必须保证有足够的长度和随机性；如果密码由用户生成，则软件必须有“密码安全过滤”设计来拒绝接受不满足安全要求的密码。
l 禁止以明文方式传递和存储用户密码。
l 使用第三方代码，应对代码安全性进行评估和测试。
l 应注释代码中无用的语句.
l 对代码进行版本控制，确保代码的可用性。
l 防止程序员非授权修改代码禁止在程序中添加隐藏“恶意"的代码，防止与应用系统相关的程序员对系统的非授权修改。
4
应用开发的代码安全要求
规范代码的格式：
l 规范变量、函数的命名
l 规范程序的书写格式，确保程序的易读性
5
应用系统的安全测试：
应用系统的安全性测试包括以下内容：
l 测试前应明确测试目的,帮助所有测试人员熟悉测试的目的和意图.
l 应明确测试使用的方式，主要的测试方式有功能测试、压力测试和渗透性测试。
l 应明确测试的安全要点、测试参与人员、测试流程，并编写测试计划。
l 应根据测试计划制定测试方案,明确测试的各项要求和测试用例.
l 测试环境的硬件、软件环境和基础架构应模拟真实环境。
l 测试数据尽量避免采用真实数据,如果必须使用，应限定测试的人员，并在测试完成后全部删除.
l 系统测试和验收测试通常需要尽可能接近实际运行数据的测试数据,应避免使用含有个人信息的业务数据库。如果要使用其中信息，必须在使用之前使其失去个性化。当把运行数据用于测试目的时，应采取措施保护运行数据。
l 在与其他系统的交互性测试中,应充分考虑对其他系统的影响，选择适当的时间、方法。
l 测试完成后上线前应进行安全核查，消除测试用的后门、用户名及口令等。
l 确保测试环境的安全。应将测试环境与开发环境、生产环境相隔离,避免测试工作对业务的影响。
l 应详细记录测试过程发生的各个事件,列出测试过程中发现的问题。这些信息包括：发现了什么，在哪里发现的，当时的环境，这些问题是否可重现。
l 应根据测试的过程和测试结果，提出被测试系统、测试过程等方面的改进说明。
l 应确保测试用例、测试内容和测试结果的保密性。
6
应用系统上线投产的安全要求
规划应用系统上线所需要的资源需求和准备工作,包括但不限于以下内容：
l 应用系统上线对软件、硬件资源和网络的要求。
l 应用系统上线对相关部门、人员的要求.应明确所有参与人员的职责，要求签字确认。
l 应用系统上线的时间进度安排。
l 其它资源的详细清单。
l 应将应用系统的上线方案提交给相关部门主管，只有批准方可进行。
l 分析应用系统上线可能存在的风险，并制定风险规避方案。
7
应用系统上线投产的安全要求
应用系统上线过程中的安全控制：
l 应确保应用系统上线环境（硬件环境、操作系统、物理环境）的安全.
l 对应用系统即将上线投产所在的系统进行备份。
l 只对上线所需要的帐号提供最小的访问权限，防止进行其它与上线无关的活动。
l 上线的过程应有业务人员在场,对上线的操作需要经业务人员的确认。
l 对上线的操作过程进行必要的记录.
l 让所有参与人员的明确工作职责，签字确认。
8
应用系统上线投产的安全要求
应用系统上线结束应该遵照的安全要求：
l 应建立应用系统上线后的验收标准。并在验收之前做适当的系统测试(如系统联通性测试），上线人员应确保应用系统的验收标准和要求得到了清楚地定义、记录和测试.
l 制定错误恢复和重新启动程序，以及意外事故处理计划。

维护阶段
规范
建议
1
应用系统维护的安全要求
审计和评估
l 日常审计：定期对系统产生的日志进行阅读和分析，检查日志是否正常.
l 定期评估：应该对已经上线的应用系统进行定期的弱点评估，并考虑实际的成本和效率因素，可以进行定期的渗透测试.
2
应用系统维护的安全要求
变更管理：
变更管理需按照变更管理政策的具体要求。
3
应用系统维护的安全要求
通常应用开发人员不应直接访问生产系统,除非紧急情况并得到授权。

7