应用开发安全指南Word文档格式.docx
《应用开发安全指南Word文档格式.docx》由会员分享，可在线阅读，更多相关《应用开发安全指南Word文档格式.docx（36页珍藏版）》请在冰点文库上搜索。
2、认证与访问控制机制，应考虑：
●组件之间的信任机制；
●用户的身份认证机制；
●对于组件资源的访问控制机制。
3、组件内重要文件和数据的安全防护机制：
●存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：
⏹配置文件；
⏹用户数据，包括文件数据及数据库中的数据；
⏹临时文件和数据；
⏹与外系统或者系统内部其他组件接口用的数据文件。
●对这些重要数据的存取安全性设计，包括:
⏹文件和数据存放是否加密及采用的加密方式。
2.1.2.应用系统与外系统接口的安全
应用系统与外系统的接口安全设计，主要应考虑以下几个要素：
1、与外系统的之间通讯中的安全机制。
应充分考虑：
●传输命令和数据所采用的协议的安全性。
应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
●建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口。
2、与外系统的认证与访问控制机制，应考虑：
●系统之间的信任机制；
●对于系统之间资源的访问控制机制。
3、对外系统安全机制的符合性，应考虑：
●如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；
●如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；
●在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。
2.1.3.应用系统其他的安全机制
除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制：
1、针对Web应用的页面保护与恢复机制。
利用专用的安全产品，或者系统自身设计时就考虑到了对于Web页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。
2、针对特殊数据的完整性检查和监控机制。
应用系统自身的审计机制。
这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。
3、应用系统安全性分析。
任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。
2.2.应用系统软件功能安全设计要求
除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。
应用系统在开发中应该考虑如下五个方面的安全功能：
●安全审计；
●通讯安全（此部分内容在架构中进行了设计）；
●数据保护；
●认证与授权；
●资源保障。
2.2.1.认证与授权功能的设计
1、应用软件应包含用户身份认证体系的强度设计,重要系统（例如2.2级别以上系统）应使用双因素认证措施，加强系统安全性：
●用户名、口令认证；
●一次性口令、动态口令认证；
●证书认证；
（可选）
●生物特征的认证（签名、声音、指纹、虹膜、视网膜等）。
2、应用软件应包含认证失败后的处理方式设计
●连续失败3次，将锁定登录账号一个小时。
账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；
●通知用户认证失败，防止黑客暴力猜测；
●验证码的功能；
●账号复杂度提醒功能。
3、应用软件应包含用户权限分配和管理功能设计。
●系统编码中要实现读、写、执行三个权限的分离设计；
●系统查看、配置、修改、删除、登录、运行等权限设计；
●数据访问范围的权限设计；
●应用功能模块使用权限的设计。
4、应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每
一个对外接口应详细说明：
●需要通信的对方系统的安全状况和可信程度；
●需传送的数据的保密性和完整性要求；
●对传送数据的合法性检验规则；
●对通信可靠性的要求；
●与外部系统的互相认证方面的需求。
5、应用系统认证与授权功能除满足上述要求外，具体要求请参考《IT安全管控平台建设规范》中安全支撑平台建设对应用系统的集中认证授权改造要求。
2.2.2.数据安全功能
1、应用系统的数据安全功能，应当根据安全需求进行功能设计，内容涉及：
数据库的安全、数据采集、数据传输、数据处理、数据存储、数据备份和恢复的安全。
对重要的敏感数据应进行加密和完整性保护。
2、应用软件应包含输入的安全性设计，主要指对错误输入、恶意输入进行处理。
3、应用软件应包含输出的安全性设计。
2.2.3.安全审计功能
1、应用系统具备如下安全审计功能：
●审计功能的启动和关闭；
●变更审计功能的配置信息；
●至少应进行审计的事件：
进入和退出的时间（登录、退出系统）、异常的系统使用行为（失败登录）、系统维护行为、敏感行为和其它安全功能要求的审计内容；
●每个审计记录中至少记录如下信息：
事件的日期和时间、事件的类型、主题标识、事件的结果（成功、失败）和事件相关信息。
2、应用系统应支持数据查阅审计功能：
按照主题、事件查阅；
应用系统应明确用户能够查阅审计数据用户。
3、在意外情况出现时，应有措施保证审计数据的可用性，当审计记录溢出时采取保护行动。
2.2.4.容错功能设计
1、应用软件应包含各模块的出错处理设计。
2、应用软件应包含可能出现的各种异常情况的安全处理设计。
3、应用软件应包含抗网络攻击的能力的设计及系统脆弱性分析。
4、对于应用软件本身的资源及服务的优先保障设计。
2.3.应用系统存储安全设计要求
在应用系统存储安全设计时，应对系统的存储容量、存储介质、存储备份内容、存储备份方式、存储设备功能要求及相关的存储技术统筹进行考虑。
2.3.1.应用系统的存储容量设计
应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求：
在实际估算值上预留20%的存储余量，并考虑未来的应用存储量的增长需求。
考虑到应用系统自身的审计数据的容量、保存期限以配置相应的存储设备。
对于应用系统中的临时数据和过渡数据，应当设计其保存的时间，并以此考虑这部分的存储容量要求。
2.3.2.应用系统的存储介质选择
应用系统的存储介质主要包括但不限于：
磁带、纸带、闪存、软盘、光盘、磁盘和磁盘阵列。
具体存储介质的选择应依据应用系统的业务种类及存储周期的要求，采用不同的介质。
1、对于应用系统的交易数据，应采用高性能、高可靠的存储介质，如磁盘、磁盘阵列等进行存储；
2、对于应用系统的历史数据，应采用可靠、稳定的存储介质，如磁带、光盘等进行存储。
2.3.3.应用系统存储备份对象
应用系统对于其储存备份的对象设计，应包括如下内容：
1、系统数据的备份：
应包括Web服务器的网站内容、Mail服务器的邮件实时备份、数据库、文件服务器中的文件以及其他数据；
2、系统的完全备份：
应包括关键的、需要快速恢复的设备，通过磁带机的完全备份，应实现快速的灾难恢复；
3、系统的冗余主机备份：
对于关键并且不能停止的服务设备（如计费服务、Web、Mail服务器），应考虑使用多台主机进行冗余备份，以保证当任何一台主机发生故障时，服务器仍可提供服务；
4、系统配置的备份：
应包括关键路由器的配置、防火墙的配置、各类服务器操作系统的安全配置以及各类服务器（如Web、Mail、文件服务器等）中服务器软件（如Apache、Sendmail）的配置。
2.3.4.应用系统存储备份方式
应用系统应当根据不同的阶段，系统数据不同的重要程度，对数据采取不同的备份方式：
1、完全备份
使用备份介质对整个系统进行完全备份，包括系统和数据。
这种备份方式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。
它也有不足之处，即：
●定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了备份成本；
●需要备份的数据量大，因此备份所需要的时间较长。
建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时，对操作系统进行完全备份。
针对信息较小的不断变化的，且变化的内容大于50％的，定期进行完全备份。
2、增量备份
每次备份的数据只是相当于上一次备份后增加和修改过的数据。
没有重复的备份数据，节省备份介质的空间，缩短了备份时间。
这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。
建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。
3、差异备份
每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据，即采用完全备份和差异备份相结合备份策略。
如每周日进行一次完全备份，而周一至周六进行差异备份。
其优点为：
没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；
缺点为：
当发生灾难时，恢复数据比较麻烦。
建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于50％）系统，定期进行差异备份。
4、按需备份
按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。
因此它是一种非常灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。
建议应用系统在下列情况下采取按需备份：
●只需要备份很少的几个文件、目录、数据库或数据库中的表；
●备份服务器上必要的配置文件。
5、排除备份
排除备份是指排除不需要的文件后再进行备份。
从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。
建议应用系统在下列情况下考虑排除备份：
●有些文件非常大，但并不重要；
●某些文件总是导致备份异常或出错。
2.3.5.应用系统的存储设备功能要求
应用系统存储设备的功能要求应包括如下内容：
1、存储设备应保证数据的高可用性和完整性要求；
2、存储设备应具有在多主机环境下工作的能力；
3、存储设备应能方便地做到快速备份和恢复，重要系统应做到双机备份、支持热插拔；
4、存储设备应有简便的、功能强大的管理工具，做到对整个存储系统的监视与控制。
2.4.应用系统通讯安全设计要求
1、应采用安全通信协议对重要数据进行安全传输（尤其是账号、口令信息），如使用SSL/TLS、HTTPS、S等安全协议进行通信：
●终端与服务器端之间的WWW服务，建议使用HTTPS安全通信协议；
●终端与服务器端之间的FTP服务，建议使SFTP安全通信协议；
●终端与服务器端之间的Telnet服务，建议使SSH安全通信协议。
2、终端应用程序采用加密传输机制对重要信息进行传输。
3、终端应用程序采用完整性检查对业务的重要数据或敏感数据进行检查。
4、终端应用程序应采用抗抵赖攻击技术对重要的交互信息进行保护。
5、终端应用程序使用固定的通信端口。
2.5.应用系统数据库安全设计要求
1、应从以下方面进行数据库的选型：
●数据库、应用系统的运行环境；
●数据库的稳定性、安全性（多级安全）；
●数据库的容量（最多支持的库的数目、表的数目、记录数目）；
●数据库的存取速度；
●是否支持多种备份方式；
●是否支持数据库的导入和导出。
2、应明确数据库相关的用户管理、资源管理、特权管理和角色管理，明确各种用户的资源权限，并建立规范的权限文档。
3、数据库原则上应及时更新重要补丁。
在安装补丁前应先在测试环境进行，提前进行数据备份，充分准备回退方案和应急预案。
4、数据库的配置应符合相应的基线配置要求。
5、应及时修改数据库的默认密码或将默认账号锁定、删除。
6、数据库的账号应根据业务和维护需要进行合理分配，避免账号共用。
2.6.应用系统数据安全设计要求
2.6.1.数据采集安全
应根据数据采集的内容、采集的频率、数据精确度要求、时间特性等来进行数据采集的安全要求设计，数据采集服务器和采集主机应考虑30%的系统开销及冗余。
2.6.2.数据传输安全
1、应按照数据的类型、数据的重要程度、网络的安全状况等综合因素，对数据的传输采取不同的安全保护，包括但不限于防火墙、IDS、VPN、病毒防护等安全措施。
2、应了解数据传输存在安全隐患的网络或设备，对存在安全隐患的网络采取必要的安全技术，包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。
3、应制定数据传输安全的检查方式，包括但不限于数据传输安全抗主动攻击能力检查、被动抗攻击的能力检查。
4、应保障“数据传输安全”有关的重要配置参数安全，包括但不限于口令、加/解密算法、加/解密密钥等。
5、应采用安全通信协议对数据进行安全传输，如使用SSL/TLS、HTTPS、S等安全协议进行通信。
6、对传输的信息进行不同等级的加密保护，即根据网络或设备的风险、传输内容安全要求的不同，选择不同安全强度的加密算法对信息进行加密传输。
建议使用RSA等高强度的密码算法对非常重要的信息（如口令、加密密钥）进行加密传输；
对于普通数据的传输，可以采用DES、3DES等加密算法进行加密传输。
7、应防止对所传输数据进行XX的任何形式的修改，即对业务的重要数据或敏感数据，建议使用MD5、SHA等算法对数据完整性进行保护。
8、对重要的交互信息，建议采取抗抵赖技术，包括但不限于数字签名技术。
9、为了配合网络其它安全设备，建议采用基于用户名/口令的认证技术、VLAN技术、MPLS技术等安全技术手段。
2.6.3.数据处理安全
1、应根据数据的类型、数据的处理方式、数据的安全性要求、与其它接口有关的敏感等级、数据相关业务应用的重要性程度来进行数据处理过程的安全性设计。
2、应对原始数据进行检错和校验操作，保证原始数据的正确性和完整性。
3、数据在转换过程中，应采用通用的标准格式，应考虑相关的不同系统和不同应用的格式需求。
4、数据处理过程应提供处理数据的状态信息和数据处理过程的动态信息。
5、数据处理过程应具备异常处理功能，在任一环节发现问题，均应能及时回退，必要时可以人工处理。
6、数据处理的中间过程和中间结果不能暴露给第三方。
3.应用系统编码安全
3.1.基本代码安全要求
3.1.1.输入验证
对函数入口参数的合法性和准确性进行检查，具体如下：
在B/S环境下，应进行服务端的验证而不仅仅是客户端的验证（例如基于Javascript的验证）。
通过在客户端和服务器之间放置一个代理服务器，可以很容易绕过客户端验证。
有了代理服务器，攻击者可以在数据被客户端“验证”后修改数据（与“man-in-the-middle”攻击类似）。
在实际的校验中，输入校验首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。
如果输入中包含无效的字符，应用程序应该返回错误页面并说明输入中包含无效字符。
这样进行验证的原因是定义无效的字符集比较困难，并且一些不应该有效的字符通常不会被指出。
另外，边界检查（例如字符串的最大长度）应该在字符有效性检查以前进行，边界分析可以防止大多数缓冲区溢出漏洞。
从环境变量获得的数据也需要进行验证，同时避免在环境变量中存放敏感数据（例如密码）。
3.1.2.SQL语句
如果应用程序需要连接后端数据库，使用存储过程而不能在代码中使用SQL语句，使用程序以外的嵌入在代码中的SQL语句调用特别危险，难以防止攻击者使用输入域或者配置文件（由应用程序载入）来执行嵌入式的SQL攻击。
当然，输入验证有助于缓解这种风险。
3.1.3.注释代码
当应用程序在实际环境中开始应用时，应该删除所有的注释代码。
注释代码是用来调试或者测试的，它们不是最终应用程序的一部分。
无论如何应该在实际的环境中删除它们以避免意外的执行（一般注释标识被删除后就无法激活休眠的代码，但还是存在可能性的，所以强烈建议执行这项工作）。
3.1.4.错误消息
所有为用户显示的错误信息都不应该暴露任何关于系统、网络或应用程序的敏感信息。
如果可能，应使用包含编号的一般的错误信息，这种信息只有开发者和/或支持小组才能理解，如“发生了错误（代码1234），请您与系统维护部门联系。
3.1.5.URL内容
对于Web应用，不能在URL上暴露任何重要信息，例如密码、服务器名称、IP地址或者文件系统路径（暴露了Web服务器的目录结构），这些信息可以在攻击时被使用。
3.1.6.设置PATH变量
设置PATH为一个已知的值，而不是仅仅使用启动时的缺省值。
攻击者可以在攻击应用程序时使用PATH变量，例如试图执行一个任意的程序，这些可以应用于大多数其他的语言。
3.1.7.其他要求
1、禁止使用XX和验证的代码。
2、使用第三方代码，应对代码安全性进行评估和测试。
3、测试用的“后门”，应在发布版中去除。
4、规范代码的格式。
●规范变量、函数的命名；
●规范程序的书写格式，确保程序的易读性。
5、对代码进行版本控制，确保代码的可用性。
6、防止程序员非授权修改代码
●对代码的访问权限进行严格的权限控制；
●禁止在程序中添加隐藏“恶意”的代码，防止与应用系统相关的程序员
对系统的非授权修改。
7、应用系统不应在程序或进程中固化账号和口令。
8、系统应具备对口令猜测的防范机制和监控手段。
9、避免应用程序以错误的顺序运行，或者防止出现故障时，后续程序以不正常的流程运行。
10、采用正确的故障恢复程序，确保正确处理数据。
11、采取会话控制或批次控制，确保更新前后数据文件的一致性，例如：
检查操作前后文件打开和关闭的数目是否一致。
12、检查执行操作前后对象的差额是否正常，如：
句柄处理，堆栈等系统资源的占用与释放等。
13、严格验证系统生成的数据。
14、在网络传输过程中检查下载/上传的数据或软件的完整性。
15、检查文件与记录是否被篡改。
例如通过计算哈希值（HASH）进行对比。
3.2.Web编程安全基本要求
3.2.1.输入检查安全
1、限制用户输入HTML和Script（JavaScript、VBScript）代码。
即，输入恶意HTML或Script（JavaScript、VBScript）代码可能会对其他浏览者造成混淆、欺骗或恶意破坏的结果。
2、检查用户输入数据的长度。
即输入超出限定长度的数据，可能造成服务器端程序溢出。
3、防止用户输入特殊字符改变SQL语义。
即，输入含特殊字符的字串，篡改SQL语句的语义，可能造成SQL查询执行不该执行的操作，以此绕过身份认证获取非法权限、甚至对数据进行破坏。
4、限制用户能够访问的最顶层目录。
即，编写对服务器端文件、目录操作的程序时应该注意限定此类程序能够访问的最顶层目录，防止用户构造输入字串借助程序功能访问服务器关键文件导致泄漏服务器敏感信息。
5、对所有类型的用户输入都要做检查，并严格限定什么是合法的用户输入，限定一个合法输入的范围，同时过滤有可能造成危险的特殊字符。
6、对不可信任域发送到可信任域的数据一定要进行检查。
7、尽可能在服务器端完成用户输入检查，不能轻易相信客户端脚本的检查结果。
即，虽然客户端的Script脚本能完成一部分的用户输入检查功能，但这种检查的结果是不可信任的，攻击者可以自己制作表单程序绕过客户端脚本验证，将非法数据提交到服务器。
8、在输入变为输出时，也要对特殊字符做检查和转换。
3.2.2.敏感数据的存放和传递安全
1、敏感数据不能存放在Web页中。
2、不能把敏感的数据存储在cookie、隐藏字段或者潜在地可能会被用户修改的地方。
3、客户端向服务器端提交敏感数据应该经过加密（例如使用SSL），尽量不能明文传输。
4、密码等敏感信息存放在数据库中应该加密，并采用健壮的加密算法。
5、防止数据库被攻破后泄漏用户密码。
3.2.3.缓冲区溢出安全
1、所有的输入都必须进行正确的有效性检测。
2、必须保证数组没有越界，增加数组操作函数的边界检查。
3、安全地使用字符串处理函数，慎用有安全隐患的字符串处理函数
4、使用Format字符串的时候特别注意Unicode和ANSI的大小不一致的情况。
5、注意字符串结束符的保护。
6、仔细研究库函数内部的缓冲区分配，明确其限制。
不能使用realpath（）等函数，如果功能需要必须使用时，一定要检查试图规范化的路径的长度，确保其不长于MAXPATHLEN。
7、时刻进行边界检查。
建议使用一些检查工具：
Purify、Stackguard等检查代码，保证没有缓冲区溢出的问题。
3.2.4.格式化字符串安全
1、使用固定的格式化字符串，或者来自可信源的格式化字符串。
2、要检查并限定locale的请求为合法值。
3、不能将用户输入直接作为格式化字符传给格式化函数。
3.2.5.整数溢出安全
1、对于涉及到内存分配大小的计算，要进行仔细检查，确保计算不会产生溢出。
2、对于涉及到数组索引的计算，要进行仔细检查，确保计算不会产生溢出。
3、要使用无符号整数表示数组偏移和内存分配大小。
3.2.6.SQL注入代码安全
1、要检查输入的有效性和可信度。
2、要使用参数化的查询、占位符、或者参数绑定来构造SQL语句。
3、要在程序之外存储数据库的连接信息，比如经过保护的配置文件或者Windows注册表。
4、即使使用的是存储过程，也不能使用字符串连接来构造SQL语句。
5、不能在存储过程内部使
升级会员 