本文为收大量资料集整理并修改，有些涉及技术方面的已经比较旧，欢迎大家一起完善和提建议。
1、概述
本指南是IT安全保障体系建设规范的一个组成部分，全面阐述了IT系统应用开发整个软件生命周期所必须遵照的设计、编码、测试方面的安全要求，阐述了不同开发环境和编码语言条件下安全开发的相关规范要求。
1.1目的
本指南针对应用系统应当遵循的应用开发安全标准进行了规范性说明，旨在指导应用系统设计人员、代码开发人员和安全检查管理人员进行应用安全开发的安全配置，以提高应用系统的安全防护能力。
1.2适用范围
本指南适用于代码开发项目，作为在IT系统开发、设计环节中所遵照执行的依据。
1.3适用对象
本配置指南的适用人员包括：系统应用开发人员及安全检查管理人员。
2、应用系统设计安全
2.1应用系统架构安全设计要求
在应用系统设计阶段，应充分考虑该架构的安全性,包括B/S、C/S等形式的安全，主要体现在应用数据和用户会话的安全，还应当考虑应用系统自身体系架构内部的安全，以及与外系统接口的安全。针对某些特殊应用，还需考虑复、抗攻击等安全机制。所有的安全设计都是为了保证系统的稳定性和连续性，有针对性的解决自身安全问题。
2.1.1应用系统自身架构安全
1、自身结构中各组件之间通讯过程的安全机制
组件之间的通讯包括命令级的和数据级的，应充分考虑：
l传输命令和数据所采用的协议的安全性。应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
l考虑程序的模块之间的安全通讯机制；
l不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。
2、认证与访问控制机制，应考虑：
l组件之间的信任机制；
l用户的身份认证机制；
l对于组件资源的访问控制机制；
l不通用户对资源的权限控制机制。
3、组件内重要文件和数据的安全防护机制：
存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：
l配置文件；
l用户数据，包括文件数据及数据库中的数据；
l临时文件和数据；
l与外系统或者系统内部其他组件接口用的数据文件。
对这些重要数据的存取安全性设计，包括:
l文件和数据存放是否加密及采用的加密方式。
2.1.2应用系统与外系统接口的安全
应用系统与外系统的接口安全设计，主要应考虑以下几个要素：
1、与外系统的之间通讯中的安全机制。应充分考虑：
l传输命令和数据所采用的协议的安全性。应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
l建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口，传输过程使用加密传输。
2、与外系统的认证与访问控制机制，应考虑：
l系统之间的信任机制；
l会话凭据的有效时间；
l可以访问资源的权限控制；
l对于系统之间资源的访问控制机制。
3、对外系统安全机制的符合性，应考虑：
l如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；
l如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；
l在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。
2.1.3应用系统其他的安全机制
除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制：
1、针对Web应用的页面保护与恢复机制。
利用专用的安全产品，或者系统自身设计时就考虑到了对于Web页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。
2、针对特殊数据的完整性检查和监控机制。
应用系统自身的审计机制。这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。
3、针对重要系统的DDOS攻击的解决方案。
4、应用系统安全性分析。
5、除了使用技术手段保证接口安全的同时，也需要保证接口相关代码和文件不被上传到互联网或泄漏给非必要人员。
任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。
2.2应用系统软件功能安全设计要求
除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。应用系统在开发中应该考虑如下几个方面的安全功能：
l安全审计；
l通讯安全（此部分内容在架构中进行了设计）；
l数据保护；
l认证与授权；
l资源保障；
l最小权限。
2.2.1认证与授权功能的设计
1、应用软件应包含用户身份认证体系的强度设计,重要系统应使用双因素或多因素认证措施，加强系统安全性：
l用户名、口令认证；
l一次性口令、动态口令认证；
l证书认证；（可选）
l生物特征的认证（签名、声音、指纹、虹膜、视网膜等）。（可选）
2、应用软件应包含认证失败后的处理方式设计
l连续失败3次，将锁定登录账号一个小时。账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；
l通知用户认证失败，防止黑客暴力猜测；
l验证码的功能，需要一定复杂度，防止被机器识别；
l账号复杂度提醒功能。
3、应用软件应包含用户权限分配和管理功能设计。
l系统编码中要实现读、写、执行三个权限的分离设计；
l系统查看、配置、修改、删除、登录、运行等权限设计；
l数据访问范围的权限设计；
l针对不同用户的数据库表权限隔离；
l应用功能模块使用权限的设计。
4、应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每一个对外接口应详细说明：
l需要通信的对方系统的安全状况和可信程度；
l需传送的数据的保密性和完整性要求；
l对传送数据的合法性检验规则；
l对通信可靠性的要求；
l与外部系统的互相认证方面的需求；
l信息传输过程的加密需求。
2.2.2数据安全功能
1、应用系统的数据安全功能，应当根据安全需求进行功能设计，内容涉及：数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。对重要的敏感数据应进行加密和完整性保护。
2、应用软件应包含输入的安全性设计，主要指对错误输入、恶意输入进行处理。
3、应用软件应包含输出的安全性设计。
2.2.3安全审计功能
1、应用系统具备如下安全审计功能：
l审计功能的启动和关闭；
l变更审计功能的配置信息；
l至少应进行审计的事件：进入和退出的时间(登录、退出系统)、异常的系统使用行为(失败登录)、系统维护行为、敏感行为和其它安全功能要求的审计内容；
l每个审计记录中至少记录如下信息：事件的日期和时间、事件的类型、主题标识、事件的结果(成功、失败)和事件相关信息。
2、应用系统应支持数据查阅审计功能：按照主题、事件查阅；应用系统应明确用户能够查阅审计数据用户。
3、在意外情况出现时，应有措施保证审计数据的可用性，当审计记录溢出时采取保护行动。
2.2.4容错功能设计
1、应用软件应包含各模块的出错处理设计。
2、应用软件应包含可能出现的各种异常情况的安全处理设计，如：错误信息不回显给用户。
3、应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。
4、对于应用软件本身的资源及服务的优先保障设计。
2.3应用系统存储安全设计要求
在应用系统存储安全设计时，应对系统的存储容量、存储介质、存储备份内容、存储备份方式、存储设备功能要求及相关的存储技术统筹进行考虑。
2.3.1应用系统的存储容量设计
应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求：
l在实际估算值上预留30%的存储余量，并考虑未来的应用存储量的增长需求。
l考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。
l对于应用系统中的临时数据和过渡数据，应当设计其保存的时间，并以此考虑这部分的存储容量要求。
2.3.2应用系统的存储介质选择
应用系统的存储介质主要包括但不限于：磁带、光盘、磁盘、磁盘阵列和云存储。具体存储介质的选择应依据应用系统的业务种类及存储周期的要求，采用不同的介质。
1、对于应用系统的交易数据，应采用高性能、高可靠的存储介质，如磁盘、磁盘阵列、云存储等进行存储；
2、对于应用系统的历史数据，应采用可靠、稳定的存储介质，如磁带、光盘等进行存储。
2.3.3应用系统存储备份对象
应用系统对于其储存备份的对象设计，应包括如下内容：
1、系统数据的备份：应包括Web服务器的网站内容、Mail服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据；
2、系统的完全备份：应包括关键的、需要快速恢复的设备，通过磁带机的完全备份，应实现快速的灾难恢复；
3、系统的冗余主机备份：对于关键并且不能停止的服务设备（如计费服务、Web、Mail服务器），应考虑使用多台主机进行冗余备份，以保证当任何一台主机发生故障时，服务器仍可提供服务；
4、系统配置的备份：应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器（如Web、Mail、文件服务器等）中间件和容器（如Apache、tomcat、nginx、weblogic等）的配置。
2.3.4应用系统存储备份方式
应用系统应当根据不同的阶段，系统数据不同的重要程度，对数据采取不同的备份方式：
1、完全备份
使用备份介质对整个系统进行完全备份，包括系统和数据。这种备份方
式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。它也有不足之处：
l定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了备份成本；
l需要备份的数据量大，因此备份所需要的时间较长。
l建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时，对操作系统进行完全备份。针对信息较小的不断变化的，且变化的内容大于50％的，定期进行完全备份。
2、增量备份
每次备份的数据只是相当于上一次备份后增加和修改过的数据。没有重复的备份数据，节省备份介质的空间，缩短了备份时间。这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。
建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。
3、差异备份
每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据，即采用完全备份和差异备份相结合备份策略。如：每周日进行一次完全备份，而周一至周六进行差异备份。其优点为：没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；缺点为：当发生灾难时，恢复数据比较麻烦。
建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于
50％）系统，定期进行差异备份。
4、按需备份
按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。因此它是一种非常灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。
建议应用系统在下列情况下采取按需备份：
l只需要备份很少的几个文件、目录、数据库或数据库中的表；
l备份服务器上必要的配置文件。
5、排除备份
排除备份是指排除不需要的文件后再进行备份。从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。
建议应用系统在下列情况下考虑排除备份：
l有些文件非常大，但并不重要；
l某些文件总是导致备份异常或出错。
6、备份恢复测试
不管是全备、增备、差异、按需还是排除备份，都应该定期对已被分的数据进行恢复测试，保证备份数据的可用性，在关键时刻可以及时并快速的恢复系统。
2.3.5应用系统的存储设备功能要求
应用系统存储设备的功能要求应包括如下内容：
1、存储设备应保证数据的高可用性和完整性要求；
2、存储设备应具有在多主机环境下工作的能力；
3、存储设备应能方便地做到快速备份和恢复，重要系统应做到双机备份、支持热插拔；
4、存储设备应有简便的、功能强大的管理工具，做到对整个存储系统的监视与控制。
2.4应用系统通讯安全设计要求
1、应采用安全通信协议对重要数据进行安全传输（尤其是账号、口令信息），如使用SSL/TLS、HTTPS、SFTP和IPSec、SCP等安全协议进行通信：终端与服务器端之间的WWW服务，建议使用HTTPS安全通信协议；终端与服务器端之间的FTP服务，建议使SFTP安全通信协议；终端与服务器端之间的Telnet服务，建议使SSH安全通信协议。
2、终端应用程序采用加密传输机制对重要信息进行传输。
3、终端应用程序采用完整性检查对业务的重要数据或敏感数据进行检查。
4、终端应用程序应采用抗抵赖攻击技术对重要的交互信息进行保护。
5、终端应用程序使用固定的通信端口。
6、对于需要映射到公网的端口，不要使用原端口，在条件允许的情况下使用白名单访问。
2.5应用系统数据库安全设计要求
1、应从以下方面进行数据库的选型：
l数据库、应用系统的运行环境；
l数据库的稳定性、安全性（多级安全）；
l数据库的容量（最多支持的库的数目、表的数目、记录数目）；
l数据库的存取速度；
l是否支持多种备份方式；
l是否支持数据库的导入和导出。
2、应明确数据库相关的用户管理、资源管理、特权管理和角色管理，明确各种用户的资源权限，并建立规范的权限文档。
3、数据库原则上应及时更新重要补丁。在安装补丁前应先在测试环境进行，提前进行数据备份，充分准备回退方案和应急预案。
4、数据库的配置应符合相应的基线配置要求。
5、应及时修改数据库的默认密码或将默认账号锁定、删除。
6、数据库的账号应根据业务和维护需要进行合理分配，避免账号共用。
7、数据库每个用户之间的权限需要隔离。
8、需要对数据库操作进行审计，包含：账号、操作、时间等指标。
2.6应用系统数据安全设计要求
2.6.1数据采集安全
应根据数据采集的内容、采集的频率、数据精确度要求、时间特性等来进行数据采集的安全要求设计，数据采集服务器和采集主机应考虑30%的系统开销及冗余。
2.6.2数据传输安全
1、应按照数据的类型、数据的重要程度、网络的安全状况等综合因素，对
数据的传输采取不同的安全保护，包括但不限于防火墙、IDS、IPSEC-VPN、病毒防护等安全措施。
2、应了解数据传输存在安全隐患的网络或设备，对存在安全隐患的网络采取必要的安全技术，包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。
3、应制定数据传输安全的检查方式，包括但不限于数据传输安全抗主动攻击能力检查、被动抗攻击的能力检查。
4、应保障“数据传输安全”有关的重要配置参数安全，包括但不限于口令、加/解密算法、加/解密密钥等。
5、应采用安全通信协议对数据进行安全传输，如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信。
6、对传输的信息进行不同等级的加密保护，即根据网络或设备的风险、传输内容安全要求的不同，选择不同安全强度的加密算法对信息进行加密传输。建议使用RSA等高强度的密码算法对非常重要的信息（如口令、加密密钥）进行加密传输；对于普通数据的传输，可以采用RSA、3DES等相对安全的加密算法进行加密传输。
7、应防止对所传输数据进行未经授权的任何形式的修改，即对业务的重要数据或敏感数据，建议使用MD5、SHA等算法对数据完整性进行保护。
8、对重要的交互信息，建议采取抗抵赖技术，包括但不限于数字签名技术。
9、为了配合网络其它安全设备，建议采用基于用户名/口令的认证技术、VLAN技术、MPLS技术等安全技术手段。
2.6.3数据处理安全
1、应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。
2、应对原始数据进行检错和校验操作，保证原始数据的正确性和完整性。
3、数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格式需求。
4、数据处理过程应提供处理数据的状态信息和数据处理过程的动态信息。
5、数据处理过程应具备异常处理功能，在任一环节发现问题，均应能及时回退，必要时可以人工处理。
6、数据处理的中间过程和中间结果不能暴露给第三方。
3、应用系统开发安全
3.1安全原则
1、保护最薄弱的环节原则：保护最易受攻击影响的部分；
2、纵深防御原则：不同层面、不同角度之间需要相互配合；
3、最小权限原则：只授予执行操作所需的最小权限；
4、最小共享原则：使共享文件资源尽可能少；
5、权限分离原则：授予不同用户所需的最小权限，并在它们之间形成相互制约的关系；
3.2需求管理阶段
1、根据业务目标分析并制定系统安全目标；
2、确认安全需求规格说明。
3.3系统设计阶段
1、根据安全目标执行威胁建模，识别威胁和风险；
2、根据威胁建模制定对应开发安全任务：
l确定安全体系架构，设计安全协议和安全接口；
l确定访问控制与身份鉴别机制，定义主体角色和权限；
l信息输入的安全过滤，信息输出的校验和控制；
l数据结构安全设计，选择加密方法和算法；
l确定敏感数据保护方法；
l内部处理逻辑安全设计；
l评估内部通信机制，确定完整性机制。
3.4系统实现阶段
1、开发环境安全管理要求：
l软件系统开发、测试禁止在生产环境中进行；
l开发环境中的开发用机应进行统一安全配置及时进行系统补丁升级和漏洞修复；
l软件程序不得篡改应用软件所运行的环境或平台中任何安全配置、安全文件和安全程序。
2、编码安全要求（后面会有详细讲解）：
l遵循代码编写安全规范，根据代码编写安全规范以及安全设计方案进行系统开发；
l遵循通用安全编程准则，包括输入验证、缓存溢出、安全调用组件和程序编译等；
l遵循机密性要求，保护用户访问信息的机密性，严禁在客户端存放敏感数据
l避免内存溢出，严格检查和验证输入输出信息等；
l遵循结构化异常处理机制，捕捉并处理程序异常，防止系统信息泄露
l遵循代码脆弱性防范要求，包括缓冲区溢出、SQL注入、跨站脚本攻击、XML注入攻击、HTTP HEAD注入等。
3、开发流程安全要求：
l开发过程中应对阶段性开发成果进行有效管理；
l开发过程中应定期进行代码静态分析，使用代码审核工具对源代码进行检测，并报告源代码中存在的安全弱点；
l开发人员不得超越其规定权限进行开发，不得在程序中设置后门或恶意代码程序。
3.5系统测试阶段
1、测试内容应包括代码的安全测试和安全功能测试；
2、代码的安全测试是指使用代码测试工具或渗透测试来识别代码的安全脆弱性，并应按照其提供的修复建议进行修复；
3、安全功能测试主要包括身份认证和访问控制的功能测试；
4、测试系统环境应尽可能模拟生产环境并与生产环境进行安全隔离；
5、真实数据不得直接在测试环境中使用，须进行适当修改或屏蔽，在测试完成之后须立即从测试应用系统清除运行信息；
6、测试人员编制安全测试方案，构造安全测试用例；
7、验收测试不得由开发人员兼岗。
3.6系统上线阶段
1、系统上线须在内部验收通过后进行；
2、需进行上线前试运行，确认应用系统是否符合上线要求；
3、上线成功后，记录上线的日期和内容。
3.7文档管理
1、源代码的变更和版本发布进行统一控制，对程序资源库的任何修改、更新和发布都需经部门主管领导授权和批准；
2、应指定专人妥善保管程序源代码及相关技术文档。
3.8外包管理
1、应与外包开发单位签署相关知识产权保护协议和保密协议；
2、外包开发单位进行系统开发过程中须严格遵循本制度的相关安全要求；
3、在系统开发过程中须指派专人监督审核外包开发单位在各个阶段安全要求的执行情况；
4、外包开发单位在系统开发完成后提供程序源代码和相关技术文档，不得将计算机系统采用的关键安全技术措施和核心安全功能设计对外公开；
5、应对开发完成后的应用软件进行审查或检测。
