应用开发安全指南.doc

1、应用开发安全指南1. 概述本指南的编制是在CTG-MBOSS IT 总体规范 V1.0的总体框架体系指导下，参考了中国电信CTG-MBOSS IT 安全规范 V1.0及近年来发布的其他安全政策和指导意见相关内容，继承和吸收了原有安全管理实践的经验成果，并充分考虑了各省电信公司的现状和行业最佳实践与安全新技术的引入。本指南是IT 安全保障体系建设规范的一个组成部分，全面阐述了IT 系统应用开发整个软件生命周期所必须遵照的设计、编码、测试方面的安全要求，阐述了不同开发环境和编码语言条件下安全开发的相关规范要求。1.1.目的本指南针对中国电信IT 应用系统应当遵循的应用开发安全标准进行了规范性说明，

2、旨在指导应用系统设计人员、代码开发人员和安全检查管理人员进行应用安全开发的安全配置，以提高应用系统的安全防护能力。1.2.适用范围本指南适用于中国电信IT 系统代码开发项目，作为中国电信集团公司、各省公司在IT 系统开发、设计环节中所遵照执行的依据。1.3.适用对象本配置指南的适用人员包括：中国电信IT 系统应用开发人员及安全检查管理人员。1.4.规范文档应用开发安全指南在中国电信集团公司IT 安全保障体系建设规范中的位置如下图所示：策略规范指南管理分册技术分册中国电信IT安全保障体系建设规范要求规范指南规范总册2. 应用系统设计安全2.1. 应用系统架构安全设计要求在应用系统设计阶段，应充分

3、考虑该架构的安全性,包括B/S、C/S 等形式的安全，主要体现在应用数据和用户会话的安全，还应当考虑应用系统自身体系架构内部的安全，以及与外系统接口的安全。针对某些特殊应用，还需考虑恢复、抗攻击等安全机制。2.1.1. 应用系统自身架构安全1、 自身结构中各组件之间通讯过程的安全机制组件之间的通讯包括命令级的和数据级的，应充分考虑：传输命令和数据所采用的协议的安全性。应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；考虑程序的模块之间的安全通讯机制；不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。2、 认证与访问控制机制，应考虑：组件之间的信任机制；用户的身份认证机

4、制；对于组件资源的访问控制机制。3、 组件内重要文件和数据的安全防护机制：存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：配置文件；用户数据，包括文件数据及数据库中的数据；临时文件和数据；与外系统或者系统内部其他组件接口用的数据文件。对这些重要数据的存取安全性设计，包括:文件和数据存放是否加密及采用的加密方式。2.1.2.应用系统与外系统接口的安全应用系统与外系统的接口安全设计，主要应考虑以下几个要素：1、 与外系统的之间通讯中的安全机制。应充分考虑：传输命令和数据所采用的协议的安全性。应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；建议不

5、使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口。2、 与外系统的认证与访问控制机制，应考虑：系统之间的信任机制；对于系统之间资源的访问控制机制。3、 对外系统安全机制的符合性，应考虑：如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。2.1.3.应用系统其他的安全机制除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制：1、 针对We

6、b应用的页面保护与恢复机制。利用专用的安全产品，或者系统自身设计时就考虑到了对于Web 页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。2、 针对特殊数据的完整性检查和监控机制。应用系统自身的审计机制。这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。3、 应用系统安全性分析。任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。2.2. 应用系统软件功能安全设计要求除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。应用系统在开发中应该考

7、虑如下五个方面的安全功能：安全审计；通讯安全（此部分内容在架构中进行了设计）；数据保护；认证与授权；资源保障。2.2.1.认证与授权功能的设计1、 应用软件应包含用户身份认证体系的强度设计,重要系统(例如2.2级别以上系统) 应使用双因素认证措施，加强系统安全性：用户名、口令认证；一次性口令、动态口令认证；证书认证；（可选）生物特征的认证（签名、声音、指纹、虹膜、视网膜等）。（可选）2、 应用软件应包含认证失败后的处理方式设计连续失败3 次，将锁定登录账号一个小时。账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；通知用户认证失败，防止黑客暴力猜测；验证码的功能；账号复杂度提醒功能。

8、3、 应用软件应包含用户权限分配和管理功能设计。系统编码中要实现读、写、执行三个权限的分离设计；系统查看、配置、修改、删除、登录、运行等权限设计；数据访问范围的权限设计；应用功能模块使用权限的设计。4、 应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每一个对外接口应详细说明：需要通信的对方系统的安全状况和可信程度；需传送的数据的保密性和完整性要求；对传送数据的合法性检验规则；对通信可靠性的要求；与外部系统的互相认证方面的需求。5、 应用系统认证与授权功能除满足上述要求外，具体要求请参考IT安全管控平台建设规范中安全支撑平台建设对应用系统的集中认证授权改造要求。2.2.2.数据安全

9、功能1、 应用系统的数据安全功能，应当根据安全需求进行功能设计，内容涉及：数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。对重要的敏感数据应进行加密和完整性保护。2、 应用软件应包含输入的安全性设计，主要指对错误输入、恶意输入进行处理。3、 应用软件应包含输出的安全性设计。2.2.3.安全审计功能1、 应用系统具备如下安全审计功能：审计功能的启动和关闭；变更审计功能的配置信息；至少应进行审计的事件：进入和退出的时间(登录、退出系统)、异常的系统使用行为( 失败登录)、系统维护行为、敏感行为和其它安全功能要求的审计内容；每个审计记录中至少记录如下信息：事件的日期和时间

10、、事件的类型、主题标识、事件的结果(成功、失败)和事件相关信息。2、 应用系统应支持数据查阅审计功能 ：按照主题、事件查阅；应用系统应明确用户能够查阅审计数据用户。3、 在意外情况出现时，应有措施保证审计数据的可用性，当审计记录溢出时采取保护行动。2.2.4.容错功能设计1、 应用软件应包含各模块的出错处理设计。2、 应用软件应包含可能出现的各种异常情况的安全处理设计。3、 应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。4、 对于应用软件本身的资源及服务的优先保障设计。2.3. 应用系统存储安全设计要求在应用系统存储安全设计时，应对系统的存储容量、存储介质、存储备份内容、存储备份方式、

11、存储设备功能要求及相关的存储技术统筹进行考虑。2.3.1.应用系统的存储容量设计应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求：在实际估算值上预留20%的存储余量，并考虑未来的应用存储量的增长需求。考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。对于应用系统中的临时数据和过渡数据，应当设计其保存的时间，并以此考虑这部分的存储容量要求。2.3.2.应用系统的存储介质选择应用系统的存储介质主要包括但不限于：磁带、纸带、闪存、软盘、光盘、磁盘和磁盘阵列。具体存储介质的选择应依据应用系统的业务种类及存储周期的要求，采用不同的介质。1、 对于应用系

12、统的交易数据，应采用高性能、高可靠的存储介质，如磁盘、磁盘阵列等进行存储；2、 对于应用系统的历史数据，应采用可靠、稳定的存储介质，如磁带、光盘等进行存储。2.3.3.应用系统存储备份对象应用系统对于其储存备份的对象设计，应包括如下内容：1、 系统数据的备份：应包括Web服务器的网站内容、Mail服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据；2、 系统的完全备份：应包括关键的、需要快速恢复的设备，通过磁带机的完全备份，应实现快速的灾难恢复；3、 系统的冗余主机备份：对于关键并且不能停止的服务设备（如计费服务、Web 、Mail服务器），应考虑使用多台主机进行冗余备份，以保证当任

13、何一台主机发生故障时，服务器仍可提供服务；4、 系统配置的备份：应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器（如Web、Mail、文件服务器等）中服务器软件（如Apache、Sendmail）的配置。2.3.4.应用系统存储备份方式应用系统应当根据不同的阶段，系统数据不同的重要程度，对数据采取不同的备份方式：1、 完全备份使用备份介质对整个系统进行完全备份，包括系统和数据。这种备份方式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。它也有不足之处，即：定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了

14、备份成本；需要备份的数据量大，因此备份所需要的时间较长。建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时，对操作系统进行完全备份。针对信息较小的不断变化的，且变化的内容大于50的，定期进行完全备份。2、 增量备份每次备份的数据只是相当于上一次备份后增加和修改过的数据。没有重复的备份数据，节省备份介质的空间，缩短了备份时间。这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。3、 差异备份每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据，即采用完全备份和差异备

15、份相结合备份策略。如每周日进行一次完全备份，而周一至周六进行差异备份。其优点为：没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；缺点为：当发生灾难时，恢复数据比较麻烦。建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于50）系统，定期进行差异备份。4、 按需备份按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。因此它是一种非常灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。建议应用系统在下列情况下采取按需备份：只需要备份很少的几个文件、目录、数据库或数据库中的表；备份服务器上必

16、要的配置文件。5、 排除备份排除备份是指排除不需要的文件后再进行备份。从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。建议应用系统在下列情况下考虑排除备份：有些文件非常大，但并不重要；某些文件总是导致备份异常或出错。2.3.5.应用系统的存储设备功能要求应用系统存储设备的功能要求应包括如下内容：1、 存储设备应保证数据的高可用性和完整性要求；2、 存储设备应具有在多主机环境下工作的能力；3、 存储设备应能方便地做到快速备份和恢复，重要系统应做到双机备份、支持热插拔；4、 存储设备应有简便的、功能强大的管理工具，做到对整个存储系统的监视与控制。2.4. 应用系统通讯安全设计要求

17、1、 应采用安全通信协议对重要数据进行安全传输（尤其是账号、口令信息），如使用SSL/TLS、HTTPS、SFTP和IPSec 等安全协议进行通信：终端与服务器端之间的WWW 服务，建议使用HTTPS 安全通信协议；终端与服务器端之间的FTP 服务，建议使SFTP 安全通信协议；终端与服务器端之间的Telnet 服务，建议使SSH 安全通信协议。2、 终端应用程序采用加密传输机制对重要信息进行传输。3、 终端应用程序采用完整性检查对业务的重要数据或敏感数据进行检查。4、 终端应用程序应采用抗抵赖攻击技术对重要的交互信息进行保护。5、 终端应用程序使用固定的通信端口。2.5. 应用系统数据库安全

18、设计要求1、 应从以下方面进行数据库的选型：数据库、应用系统的运行环境；数据库的稳定性、安全性（多级安全）；数据库的容量（最多支持的库的数目、表的数目、记录数目）；数据库的存取速度；是否支持多种备份方式；是否支持数据库的导入和导出。2、 应明确数据库相关的用户管理、资源管理、特权管理和角色管理，明确各种用户的资源权限，并建立规范的权限文档。3、 数据库原则上应及时更新重要补丁。在安装补丁前应先在测试环境进行，提前进行数据备份，充分准备回退方案和应急预案。4、 数据库的配置应符合相应的基线配置要求。5、 应及时修改数据库的默认密码或将默认账号锁定、删除。6、 数据库的账号应根据业务和维护需要进行

19、合理分配，避免账号共用。2.6.应用系统数据安全设计要求2.6.1.数据采集安全应根据数据采集的内容、采集的频率、数据精确度要求、时间特性等来进行数据采集的安全要求设计，数据采集服务器和采集主机应考虑30%的系统开销及冗余。2.6.2.数据传输安全1、 应按照数据的类型、数据的重要程度、网络的安全状况等综合因素，对数据的传输采取不同的安全保护，包括但不限于防火墙、IDS、VPN 、病毒防护等安全措施。2、 应了解数据传输存在安全隐患的网络或设备，对存在安全隐患的网络采取必要的安全技术，包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。3、 应制定数据传输安全的检查方式，包

20、括但不限于数据传输安全抗主动攻击能力检查、被动抗攻击的能力检查。4、 应保障“数据传输安全” 有关的重要配置参数安全，包括但不限于口令、加/解密算法、加/解密密钥等。5、 应采用安全通信协议对数据进行安全传输，如使用SSL/TLS、HTTPS、SFTP和IPSec 等安全协议进行通信。6、 对传输的信息进行不同等级的加密保护，即根据网络或设备的风险、传输内容安全要求的不同，选择不同安全强度的加密算法对信息进行加密传输。建议使用RSA等高强度的密码算法对非常重要的信息（如口令、加密密钥）进行加密传输；对于普通数据的传输，可以采用DES、3DES等加密算法进行加密传输。7、 应防止对所传输数据进行

21、未经授权的任何形式的修改，即对业务的重要数据或敏感数据，建议使用MD5、SHA 等算法对数据完整性进行保护。8、 对重要的交互信息，建议采取抗抵赖技术，包括但不限于数字签名技术。9、 为了配合网络其它安全设备，建议采用基于用户名/口令的认证技术、VLAN 技术、MPLS技术等安全技术手段。2.6.3.数据处理安全1、应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。2、应对原始数据进行检错和校验操作，保证原始数据的正确性和完整性。3、数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格

22、式需求。4、数据处理过程应提供处理数据的状态信息和数据处理过程的动态信息。5、数据处理过程应具备异常处理功能，在任一环节发现问题，均应能及时回退，必要时可以人工处理。6、数据处理的中间过程和中间结果不能暴露给第三方。3. 应用系统编码安全3.1. 基本代码安全要求3.1.1.输入验证对函数入口参数的合法性和准确性进行检查，具体如下：在B/S 环境下，应进行服务端的验证而不仅仅是客户端的验证（例如基于Javascript 的验证）。通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。有了代理服务器，攻击者可以在数据被客户端“验证” 后修改数据（与“man-in-the-midd

23、le”攻击类似）。在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。如果输入中包含无效的字符，应用程序应该返回错误页面并说明输入中包含无效字符。这样进行验证的原因是定义无效的字符集比较困难，并且一些不应该有效的字符通常不会被指出。另外，边界检查（例如字符串的最大长度）应该在字符有效性检查以前进行，边界分析可以防止大多数缓冲区溢出漏洞。从环境变量获得的数据也需要进行验证，同时避免在环境变量中存放敏感数据（例如密码）。3.1.2.SQL 语句如果应用程序需要连接后端数据库，使用存储过程而不能在代码中使用SQL语句，使用程序以外的嵌入在代码中的SQL

24、 语句调用特别危险，难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的SQL 攻击。当然，输入验证有助于缓解这种风险。3.1.3.注释代码当应用程序在实际环境中开始应用时，应该删除所有的注释代码。注释代码是用来调试或者测试的，它们不是最终应用程序的一部分。无论如何应该在实际的环境中删除它们以避免意外的执行（一般注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，所以强烈建议执行这项工作）。3.1.4.错误消息所有为用户显示的错误信息都不应该暴露任何关于系统、网络或应用程序的敏感信息。如果可能，应使用包含编号的一般的错误信息，这种信息只有开发者和/或支持小组才能理解，如“

25、发生了错误（代码1234），请您与系统维护部门联系。3.1.5.URL 内容对于Web 应用，不能在URL 上暴露任何重要信息，例如密码、服务器名称、 IP 地址或者文件系统路径（暴露了Web 服务器的目录结构），这些信息可以在攻击时被使用。3.1.6.设置PATH 变量设置PATH 为一个已知的值，而不是仅仅使用启动时的缺省值。攻击者可以在攻击应用程序时使用PATH 变量，例如试图执行一个任意的程序，这些可以应用于大多数其他的语言。3.1.7.其他要求1、 禁止使用未经授权和验证的代码。2、 使用第三方代码，应对代码安全性进行评估和测试。3、 测试用的“后门” ，应在发布版中去除。4、 规范

26、代码的格式。规范变量、函数的命名；规范程序的书写格式，确保程序的易读性。5、 对代码进行版本控制，确保代码的可用性。6、 防止程序员非授权修改代码对代码的访问权限进行严格的权限控制；禁止在程序中添加隐藏“ 恶意”的代码，防止与应用系统相关的程序员对系统的非授权修改。7、 应用系统不应在程序或进程中固化账号和口令。8、 系统应具备对口令猜测的防范机制和监控手段。9、 避免应用程序以错误的顺序运行，或者防止出现故障时，后续程序以不正常的流程运行。10、 采用正确的故障恢复程序，确保正确处理数据。11、 采取会话控制或批次控制，确保更新前后数据文件的一致性，例如：检查操作前后文件打开和关闭的数目是否

27、一致。12、 检查执行操作前后对象的差额是否正常，如：句柄处理，堆栈等系统资源的占用与释放等。13、 严格验证系统生成的数据。14、 在网络传输过程中检查下载/上传的数据或软件的完整性。15、 检查文件与记录是否被篡改。例如通过计算哈希值（HASH）进行对比。3.2. Web 编程安全基本要求3.2.1.输入检查安全1、 限制用户输入HTML 和 Script(JavaScript、VBScript)代码。即，输入恶意HTML 或Script（JavaScript、VBScript）代码可能会对其他浏览者造成混淆、欺骗或恶意破坏的结果。2、 检查用户输入数据的长度。即输入超出限定长度的数据，可

28、能造成服务器端程序溢出。3、 防止用户输入特殊字符改变SQL 语义。即，输入含特殊字符的字串，篡改SQL 语句的语义，可能造成SQL 查询执行不该执行的操作，以此绕过身份认证获取非法权限、甚至对数据进行破坏。4、 限制用户能够访问的最顶层目录。即，编写对服务器端文件、目录操作的程序时应该注意限定此类程序能够访问的最顶层目录，防止用户构造输入字串借助程序功能访问服务器关键文件导致泄漏服务器敏感信息。5、 对所有类型的用户输入都要做检查，并严格限定什么是合法的用户输入，限定一个合法输入的范围，同时过滤有可能造成危险的特殊字符。6、 对不可信任域发送到可信任域的数据一定要进行检查。7、 尽可能在服务

29、器端完成用户输入检查，不能轻易相信客户端脚本的检查结果。即，虽然客户端的Script 脚本能完成一部分的用户输入检查功能，但这种检查的结果是不可信任的，攻击者可以自己制作表单程序绕过客户端脚本验证，将非法数据提交到服务器。8、 在输入变为输出时，也要对特殊字符做检查和转换。3.2.2.敏感数据的存放和传递安全1、 敏感数据不能存放在Web 页中。2、 不能把敏感的数据存储在cookie、隐藏字段或者潜在地可能会被用户修改的地方。3、 客户端向服务器端提交敏感数据应该经过加密（例如使用SSL），尽量不能明文传输。4、 密码等敏感信息存放在数据库中应该加密，并采用健壮的加密算法。5、 防止数据库被

30、攻破后泄漏用户密码。3.2.3.缓冲区溢出安全1、 所有的输入都必须进行正确的有效性检测。2、 必须保证数组没有越界，增加数组操作函数的边界检查。3、 安全地使用字符串处理函数，慎用有安全隐患的字符串处理函数4、 使用Format 字符串的时候特别注意Unicode 和ANSI 的大小不一致的情况。5、 注意字符串结束符的保护。6、 仔细研究库函数内部的缓冲区分配，明确其限制。不能使用realpath ( )等函数，如果功能需要必须使用时，一定要检查试图规范化的路径的长度，确保其不长于MAXPATHLEN。7、 时刻进行边界检查。建议使用一些检查工具：Purify、Stackguard 等检查

31、代码，保证没有缓冲区溢出的问题。3.2.4.格式化字符串安全1、 使用固定的格式化字符串，或者来自可信源的格式化字符串。2、 要检查并限定locale 的请求为合法值。3、 不能将用户输入直接作为格式化字符传给格式化函数。3.2.5.整数溢出安全1、 对于涉及到内存分配大小的计算，要进行仔细检查，确保计算不会产生溢出。2、 对于涉及到数组索引的计算，要进行仔细检查，确保计算不会产生溢出。3、 要使用无符号整数表示数组偏移和内存分配大小。3.2.6.SQL 注入代码安全1、 要检查输入的有效性和可信度。2、 要使用参数化的查询、占位符、或者参数绑定来构造SQL 语句。3、 要在程序之外存储数据库

32、的连接信息，比如经过保护的配置文件或者Windows 注册表。4、 即使使用的是存储过程，也不能使用字符串连接来构造SQL 语句。5、 不能在存储过程内部使用字符串连接来构造SQL 语句。6、 不能在存储过程内部执行不可信的参数。7、 不能简单地双写单引号或者双引号。8、 不能使用高权限账号连接数据库，比如sa 或者root。9、 不能在程序或者连接字符串中存储登录口令。10、 不能在Web 根目录下存储数据库配置信息。11、 应从数据库中删除对所有用户自定义表的访问权限，同时只对存储过程授权，然后使用存储过程以及参数化的查询来构造查询字符串。3.2.7.命令注入代码安全1、 在输入命令传递给命令处理程序之前要进行验证。2、 如果输入验证失败，要安全地处理失败信息。3、 不能向任何命令解释器传递未验证的输入信息，即使这些输入仅仅是数据信息。4、 避免使用正则表达式来进行输入验证，应手工去写一些简单而又清晰的验证代码。3.2.8.异常处理代码安全1、 要检测每个安全相关函数的返回值。2、 对于每一个更改用户设定或者及其设定的函数，都要检查其返回值。