应用开发安全指南.docx

应用开发安全指南
1. 概述
本指南的编制是在《CTG-MBOSS IT 总体规范 V1.0》的总体框架体系指导下，参考了《中国电信CTG-MBOSS IT 安全规范 V1.0》及近年来发布的其他安全政策和指导意见相关内容，继承和吸收了原有安全管理实践的经验成果，并充分考虑了各省电信公司的现状和行业最佳实践与安全新技术的引入。本指南是IT 安全保障体系建设规范的一个组成部分，全面阐述了IT 系统应用开发整个软件生命周期所必须遵照的设计、编码、测试方面的安全要求，阐述了不同开发环境和编码语言条件下安全开发的相关规范要求。
1.1.目的
本指南针对中国电信IT 应用系统应当遵循的应用开发安全标准进行了规范性说明，旨在指导应用系统设计人员、代码开发人员和安全检查管理人员进行应用安全开发的安全配置，以提高应用系统的安全防护能力。
1.2.适用范围
本指南适用于中国电信IT 系统代码开发项目，作为中国电信集团公司、各省公司在IT 系统开发、设计环节中所遵照执行的依据。
1.3.适用对象
本配置指南的适用人员包括：中国电信IT 系统应用开发人员及安全检查管理人员。
1.4.规范文档
《应用开发安全指南》在中国电信集团公司IT 安全保障体系建设规范中
的位置如下图所示：
策略
规范
指南
管理分册技术分册
中国电信IT安全保障
体系建设规范
要求
规范
指南
规范总册
2. 应用系统设计安全
2.1. 应用系统架构安全设计要求
在应用系统设计阶段，应充分考虑该架构的安全性,包括B/S、C/S 等形式的安全，主要体现在应用数据和用户会话的安全，还应当考虑应用系统自身体系架构内部的安全，以及与外系统接口的安全。针对某些特殊应用，还需考虑恢复、抗攻击等安全机制。
2.1.1. 应用系统自身架构安全
1、 自身结构中各组件之间通讯过程的安全机制
组件之间的通讯包括命令级的和数据级的，应充分考虑：
l 传输命令和数据所采用的协议的安全性。应根据组件之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
l 考虑程序的模块之间的安全通讯机制；
l 不应使用标准的服务端口或者常见病毒、蠕虫等使用的服务端口。
2、 认证与访问控制机制，应考虑：
l 组件之间的信任机制；
l 用户的身份认证机制；
l 对于组件资源的访问控制机制。
3、 组件内重要文件和数据的安全防护机制：
l 存在于组件内部的重要数据资源应当考虑其相应的安全防护机制，这些重要的数据资源包括：
n 配置文件；
n 用户数据，包括文件数据及数据库中的数据；
n 临时文件和数据；
n 与外系统或者系统内部其他组件接口用的数据文件。
l 对这些重要数据的存取安全性设计，包括:
n 文件和数据存放是否加密及采用的加密方式。
2.1.2.应用系统与外系统接口的安全
应用系统与外系统的接口安全设计，主要应考虑以下几个要素：
1、 与外系统的之间通讯中的安全机制。应充分考虑：
l传输命令和数据所采用的协议的安全性。应根据系统之间通讯内容安全性要求程度的不同选择不同安全性要求的协议；
l建议不使用默认的服务端口或者常见病毒、蠕虫等使用的服务端口。
2、 与外系统的认证与访问控制机制，应考虑：
l系统之间的信任机制；
l对于系统之间资源的访问控制机制。
3、 对外系统安全机制的符合性，应考虑：
l 如果外系统采用的接口方式经评估认为是安全的，本系统应当沿用其接口规范进行设计开发；
l 如果外系统采用的接口方式经评估认为存在安全缺陷，应商定采用更加安全的接口方式；
l 在考虑接口安全性的同时，也应当注意接口方式对双方系统性能、磁盘、连接数等各种性能指标和资源的影响。
2.1.3.应用系统其他的安全机制
除了上述基本的安全架构设计内容外，针对不同的应用，以及应用系统的重要程度，可以补充考虑以下几种安全机制：
1、 针对Web应用的页面保护与恢复机制。利用专用的安全产品，或者系统自身设计时就考虑到了对于Web 页面进行静态保护和监控问题，当监控到网页被篡改时能够实时恢复页面。
2、 针对特殊数据的完整性检查和监控机制。
应用系统自身的审计机制。这一点也可算作是应用系统的安全功能设计的一部分，参见相关章节的要求。
3、 应用系统安全性分析。
任何系统都会存在一定的安全缺陷，关键在于风险和缺陷是否可以被容忍，因此，在应用系统设计完成后，应当就其安全性问题进行自我分析和评价。
2.2. 应用系统软件功能安全设计要求
除了在架构上考虑的安全机制外，这些安全机制及相关的安全功能也应当分配在应用系统软件的各部件中。应用系统在开发中应该考虑如下五个方面的安全功能：
l 安全审计；
l 通讯安全（此部分内容在架构中进行了设计）；
l 数据保护；
l 认证与授权；
l 资源保障。
2.2.1.认证与授权功能的设计
1、 应用软件应包含用户身份认证体系的强度设计,重要系统(例如2.2级别以上系统)应使用双因素认证措施，加强系统安全性：
l 用户名、口令认证；
l 一次性口令、动态口令认证；
l 证书认证；（可选）
l 生物特征的认证（签名、声音、指纹、虹膜、视网膜等）。（可选）
2、 应用软件应包含认证失败后的处理方式设计
l 连续失败3次，将锁定登录账号一个小时。账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；
l 通知用户认证失败，防止黑客暴力猜测；
l 验证码的功能；
l 账号复杂度提醒功能。
3、 应用软件应包含用户权限分配和管理功能设计。
l 系统编码中要实现读、写、执行三个权限的分离设计；
l 系统查看、配置、修改、删除、登录、运行等权限设计；
l 数据访问范围的权限设计；
l 应用功能模块使用权限的设计。
4、 应用软件应包含接口设计，应明确系统的内部结构和外部接口，对于每
一个对外接口应详细说明：
l 需要通信的对方系统的安全状况和可信程度；
l 需传送的数据的保密性和完整性要求；
l 对传送数据的合法性检验规则；
l 对通信可靠性的要求；
l 与外部系统的互相认证方面的需求。
5、 应用系统认证与授权功能除满足上述要求外，具体要求请参考《IT安全管控平台建设规范》中安全支撑平台建设对应用系统的集中认证授权改造要求。
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.应用系统的存储容量设计
应依据对于应用数据的测算，估算应用系统的存储容量，建议在存储容量估算时应考虑以下要求：
在实际估算值上预留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、 完全备份
使用备份介质对整个系统进行完全备份，包括系统和数据。这种备份方式的优点是直观，容易被人理解，而且当数据丢失时，可以快速恢复丢失的数据。它也有不足之处，即：
l定期对系统进行完全备份，因此在备份数据中有大量的重复信息，占用了大量的存贮空间，增加了备份成本；
l需要备份的数据量大，因此备份所需要的时间较长。
建议在关键性应用系统的实施前、实施后、变更以及升级等重要操作时，对操作系统进行完全备份。针对信息较小的不断变化的，且变化的内容大于50％的，定期进行完全备份。
2、 增量备份
每次备份的数据只是相当于上一次备份后增加和修改过的数据。没有重复的备份数据，节省备份介质的空间，缩短了备份时间。这种备份的优点很明显，同时也存在某些不足之处，即当发生灾难时，恢复数据比较麻烦。建议在关键性应用系统正常运行维护阶段，针对变化的、不断增加的信息，定期进行增量备份。
3、 差异备份
每次备份的数据只是相当于上一次完全备份后新增加和修改过的数据，即采用完全备份和差异备份相结合备份策略。如每周日进行一次完全备份，而周一至周六进行差异备份。其优点为：没有重复的备份数据，即节省备份介质的空间，缩短了备份时间；缺点为：当发生灾难时，恢复数据比较麻烦。建议应用系统的正常运行维护阶段，针对不断变化的（变化的内容小于50％）系统，定期进行差异备份。
4、 按需备份
按需备份是指在正常的备份安排之外，额外进行的备份操作，这种备份方式可以弥补冗余管理以及长期转存的日常备份的不足。因此它是一种非常灵活、重要的备份方式，在应用系统的各个阶段，如果备份的内容较少，可以采用按需备份。
建议应用系统在下列情况下采取按需备份：
l只需要备份很少的几个文件、目录、数据库或数据库中的表；
l备份服务器上必要的配置文件。
5、 排除备份
排除备份是指排除不需要的文件后再进行备份。从本质上讲，排除备份不是一种备份方法，只是减少备份冗余的一种方法。
建议应用系统在下列情况下考虑排除备份：
l有些文件非常大，但并不重要；
l某些文件总是导致备份异常或出错。
2.3.5.应用系统的存储设备功能要求
应用系统存储设备的功能要求应包括如下内容：
1、 存储设备应保证数据的高可用性和完整性要求；
2、 存储设备应具有在多主机环境下工作的能力；
3、 存储设备应能方便地做到快速备份和恢复，重要系统应做到双机备份、支持热插拔；
4、 存储设备应有简便的、功能强大的管理工具，做到对整个存储系统的监视与控制。
2.4. 应用系统通讯安全设计要求
1、 应采用安全通信协议对重要数据进行安全传输（尤其是账号、口令信息），如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信：
l终端与服务器端之间的WWW 服务，建议使用HTTPS 安全通信协议；
l终端与服务器端之间的FTP 服务，建议使SFTP 安全通信协议；
l终端与服务器端之间的Telnet 服务，建议使SSH 安全通信协议。
2、 终端应用程序采用加密传输机制对重要信息进行传输。
3、 终端应用程序采用完整性检查对业务的重要数据或敏感数据进行检查。
4、 终端应用程序应采用抗抵赖攻击技术对重要的交互信息进行保护。
5、 终端应用程序使用固定的通信端口。
2.5. 应用系统数据库安全设计要求
1、 应从以下方面进行数据库的选型：
l数据库、应用系统的运行环境；
l数据库的稳定性、安全性（多级安全）；
l数据库的容量（最多支持的库的数目、表的数目、记录数目）；
l数据库的存取速度；
l是否支持多种备份方式；
l是否支持数据库的导入和导出。
2、 应明确数据库相关的用户管理、资源管理、特权管理和角色管理，明确各种用户的资源权限，并建立规范的权限文档。
3、 数据库原则上应及时更新重要补丁。在安装补丁前应先在测试环境进行，提前进行数据备份，充分准备回退方案和应急预案。
4、 数据库的配置应符合相应的基线配置要求。
5、 应及时修改数据库的默认密码或将默认账号锁定、删除。
6、 数据库的账号应根据业务和维护需要进行合理分配，避免账号共用。
2.6.应用系统数据安全设计要求
2.6.1.数据采集安全
应根据数据采集的内容、采集的频率、数据精确度要求、时间特性等来进行数据采集的安全要求设计，数据采集服务器和采集主机应考虑30%的系统开销及冗余。
2.6.2.数据传输安全
1、 应按照数据的类型、数据的重要程度、网络的安全状况等综合因素，对数据的传输采取不同的安全保护，包括但不限于防火墙、IDS、VPN、病毒防护等安全措施。
2、 应了解数据传输存在安全隐患的网络或设备，对存在安全隐患的网络采取必要的安全技术，包括但不限于安全通信协议、加密算法、完整性检查算法以及抗抵赖攻击方法等。
3、 应制定数据传输安全的检查方式，包括但不限于数据传输安全抗主动攻击能力检查、被动抗攻击的能力检查。
4、 应保障“数据传输安全”有关的重要配置参数安全，包括但不限于口令、加/解密算法、加/解密密钥等。
5、 应采用安全通信协议对数据进行安全传输，如使用SSL/TLS、HTTPS、SFTP和IPSec等安全协议进行通信。
6、 对传输的信息进行不同等级的加密保护，即根据网络或设备的风险、传输内容安全要求的不同，选择不同安全强度的加密算法对信息进行加密传输。建议使用RSA等高强度的密码算法对非常重要的信息（如口令、加密密钥）进行加密传输；对于普通数据的传输，可以采用DES、3DES等加密算法进行加密传输。
7、 应防止对所传输数据进行未经授权的任何形式的修改，即对业务的重要数据或敏感数据，建议使用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、 禁止使用未经授权和验证的代码。
2、 使用第三方代码，应对代码安全性进行评估和测试。
3、 测试用的“后门”，应在发布版中去除。
4、 规范代码的格式。
l规范变量、函数的命名；
l规范程序的书写格式，确保程序的易读性。
5、 对代码进行版本控制，确保代码的可用性。
6、 防止程序员非授权修改代码
l对代码的访问权限进行严格的权限控制；
l禁止在程序中添加隐藏“恶意”的代码，防止与应用系统相关的程序员
对系统的非授权修改。
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、 不能在存储过程内部使用字符串连接来构造SQL 语句。
6、 不能在存储过程内部执行不可信的参数。
7、 不能简单地双写单引号或者双引号。
8、 不能使用高权限账号连接数据库，比如sa 或者root。
9、 不能在程序或者连接字符串中存储登录口令。
10、 不能在Web 根目录下存储数据库配置信息。
11、 应从数据库中删除对所有用户自定义表的访问权限，同时只对存储过程授权，然后使用存储过程以及参数化的查询来构造查询字符串。
3.2.7.命令注入代码安全
1、 在输入命令传递给命令处理程序之前要进行验证。
2、 如果输入验证失败，要安全地处理失败信息。
3、 不能向任何命令解释器传递未验证的输入信息，即使这些输入仅仅是数据信息。
4、 避免使用正则表达式来进行输入验证，应手工去写一些简单而又清晰的验证代码。
3.2.8.异常处理代码安全
1、 要检测每个安全相关函数的返回值。
2、 对于每一个更改用户设定或者及其设定的函数，都要检查其返回值。
3、 要有从错误条件中进行恢复的考虑，避免拒绝服务攻击。
4、 不能一次性处理所有的异常，要将异常情况进行分类处理，避免在异常处理代码中的漏洞发生。
3.2.9.跨站脚本代码安全
1、 要对所有基于Web 的输入进行输入验证和可信度验证。
2、 在没有验证合法性之前，不能对基于Web 的输入进行回显。
3、 不能在cookie 中存储敏感数据。
3.2.10.保护网络流量的代码安全
1、 要使用强大的初始认证机制。
2、 对应用程序所产生的所有网络流量都要执行过程中消息认证。
3、 尽可能使用SSL/TLS 进行网络加密传输。
3.2.11.应用中的弱口令代码安全
1、 确保口令在网络上认证时不被窃听。
2、 要在登录失败时给出错误提示，并记录失败口令尝试。
3、 尽可能使用基于hash 强壮的单向加密函数进行口令存储。
4、 为用户更改口令提供安全的机制。
5、 不得使用默认账号和默认口令，若使用，必须在首次登录后进行修改。
6、 不得在程序、后台存储明文的口令。
7、 口令要有一定的强度，应当满足系统的账号口令策略要求。
3.3. SOCKET 网络编程安全基本要求
1、 在socket 函数调用时，明确参数中绑定的端口、IP 地址和网卡接口。Windows 环境下，在遇到多个网卡的情况时，需要通过注册表来获得网卡接口和IP 地址的信息，包括Windows NT 和windows 2000。
2、 判断连接的合法身份。即，为防止恶意的连接以及可能是无效的连接，建议在socket 连接期间，判断连接的对端是否是合法的真正的连接。
3、 对于UDP 连接，可以获得连接对方的IP 地址和端口，从而可以判断对方的有效性和合法性；对于TCP 连接，由于每次连接需要三次握手，而且还有超时机制，存在两种方式来控制。
4、 对于TCP 连接，需要尽量在三次握手完成前完成判断，同时防止端口扫描的攻击。
5、 尽可能确保socket 应用能通过合理设置的防火墙。
6、 在可能的情况下，尽量减少socket 连接数目。
7、 尽量不能使用回拨的技术。
8、 尽量采用有连接状态的协议，例如TCP 协议。由于防火墙一般采取禁止一切的策略，对于UDP 协议比较难以设置。
9、 在一个应用程序中，尽量使用同一种协议，不能使用多种协议。
10、 尽量将客户端和服务器端的端口做成可以配置，不能硬编码在程序中。
3.4. JAVA 安全开发要求
JAVA 语言安全规范参考OWASP TOP 10 要求，本指南列举了常见的
JAVA 开发安全要求。
3.4.1.防范跨站脚本（XSS）
跨站脚本是最普遍的Web 应用安全漏洞。当应用程序在发送给浏览器的页面中包含用户提供的数据，但没有经过适当验证或转译，就容易导致跨站脚本漏洞。
攻击者能在受害者浏览器中执行脚本以劫持用户会话、危害网站、插入恶意内容和重定向用户等。
已知三种著名跨站漏洞是：1）存储式；2）反射式；3）基于DOM。
反射式跨站脚本通过测试或代码分析很容易找到。
防范措施：
1、验证输入
检查每个输入的有效性，主要检查输入类型和数据的长度。
2、编码输出
对验证输入的另一面就是编码输出。 编码输出是指确保字符被视为数据，而不是作为HTML 元字符被浏览器解析。 这些技术定义一些特殊的“转义”字符， 没有正确转义的数据它仍然会在浏览器中正确解析。 编码输出只是让浏览器知道数据是不是要被解析，达到攻击无法实现的目的。 需要编码的部分： HTML 实体、HTML 属性 、JavaScript 、CSS、URL。
3.4.2.防范SQL 注入
简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器把收到的数据转换成指令执行。注入漏洞十分普遍，通常能在SQL 查询、LDAP 查询、Xpath 查询、OS 命令、程序参数等中出现。注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务，注入漏洞有时甚至能导致完全接管主机。SQL 注入包含了SQL 注入、XPATH 注入、LDAP 注入、OS 命令注入等。
3.4.3.防范恶意文件执行
恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（include）功能程式的参数中修改参数内容，Web 服务器便会引入恶意程序从而受到恶意文件执行漏洞攻击。攻击者可利用恶意文件执行漏洞进行攻击取得Web 服务器控制权，进行不法利益或获取经济利益。
3.4.4.不安全的直接对象引用
所谓“不安全的对象直接引用”，即Insecure direct object references，意指一个已经授权的用户，通过更改访问时的一个参数，从而访问到原本其并没有得到授权的对象。Web 应用往往在生成Web 页面时会用它的真实名字，且并不会对所有的目标对象访问时检查用户权限，所以这就造成了不安全的对象直接引用的漏洞。
以下是不安全的对象直接引用示例：
l攻击者发现他自己的参数是6065， 即?acct=6065；
l他可以直接更改参数为6066， 即?acct=6066；
l这样他就可以直接看到6066 用户的账户信息了。
这种漏洞能损害参数所引用的所有数据。除非名字空间很稀疏，否则攻击者很容易访问该类型的所有数据。
3.4.5.防范跨站请求伪造
跨站请求伪造，也被称成为“one click attack” 或者session riding，通常缩写为CSRF 或者XSRF，是一种对网站的恶意利用。它与XSS 非常不同，并且攻击方式几乎相左。XSS 利用站点内的信任用户，而CSRF 则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS 攻击相比，CSRF 攻击往往不太流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS 更具危险性。攻击者能让受害用户修改可以修改的任何数据，或者是执行允许使用的
任何功能。
3.4.6.信息泄露和错误处理不当
应用程序常常产生错误信息并显示给使用者。很多时候，这些错误信息非常有用，因为它们揭示实施细则或有用的开发信息。
l泄露太多的细节（如错误堆栈跟踪信息、SQL 语句等等）；
l登录失败后，通知用户是否用户ID 或密码出错——登录失败可能是由于ID 或密码错误造成的。这为一个对关键资产发动蛮力攻击的攻击者提供重要信息。
3.4.7.残缺的认证和会话管理
与认证和会话管理相关的应用程序功能往往得不到正确实施，这就导致攻击者破坏密码、密钥、会话令牌或利用实施漏洞冒充其他用户身份。这些漏洞可能导致部分甚至全部账号遭受攻击。一旦攻击成功，攻击者能执行合法用户的任何操作，因此特权账号会造成更大的破坏。
编程要求：
l 使用内置的会话管理功能；
l 通过认证的问候；
l 使用单一的入口点；
l 确保在一开始登录SSL 保护的网页；
l 获取注销的权利；
l 添加超时；
l 确保你使用的是安全相关的功能；
l 使用强大的认证；
l 不进行默认身份验证。
3.4.8.不安全的加密存储
保护敏感数据已经成为网络应用的最重要的组成部分，加密的敏感数据已是非常常见安全保护手段。不加密的应用程序、设计不当或者使用不恰当的密码技术等可能导致披露敏感数据。
l 攻击者能够取得或是篡改机密的或是私有的信息；
l 攻击者通过机密秘密的窃取从而进行进一步的攻击；
l 造成企业形象破损，用户满意度下降，甚至面临法律诉讼等。
编程要求：
l 验证你的结构；
l 识别所有的敏感数据；
l 识别敏感数据存放的所有位置；
l 确保所应用的威胁模型能够应付这些攻击；
l 使用加密手段来应对威胁 ；
l 使用一定的机制来进行保护
l 文件加密；
l 数据库加密；
l 数据元素加密；
l 正确的使用这些机制；
l 使用标准的强算法；
l 合理的生成，分发和保护密钥；
l 准备密钥的变更；
l 验证实现方法；
l 确保所有的证书、密钥和密码都得到了安全的存放；
l 有一个安全的密钥分发和应急处理的方案。
3.4.9.不安全的通信
对于不加密的应用程序的网络信息传输，需要保护敏感的通信。加密（通常SSL）必须用于所有身份验证的连接，特别是通过Internet 访问的网页，以及后端的连接。否则，应用程序将暴露身份验证或会话令牌。
l 攻击者能够取得或是篡改机密的或是私有的信息；
l 攻击者通过这些秘密的窃取从而进行进一步的攻击；
l 造成企业形象破损，用户满意度下降，甚至面临法律诉讼等。
编程要求：
l 提供合理的保护机制；
l 对于敏感数据的传输，对所有连接都要使用TLS；
l 在传输前对单个数据都要进行加密；（如XML-Encryption）；
l 在传输前对信息进行签名；（如XML-Signature）；
l 正确的使用这些机制；
l 使用标准的强算法；
l 合理管理密钥和证书；
l 在使用前验证SSL 证书 。
3.4.10.限制URL 访问失效
这个漏洞事实上也是与认证相关的，与我们前面提到的不安全的直接对象引用也是类似的，不同在于这个漏洞是指系统已经对URL 的访问做了限制，但这种限制却实际并没有生效。常见的错误是，我们在用户认证只显示给用户认证过的页面和菜单选项，而实际上这些仅仅是表示层的访问控制而不能真正生效，攻击者能够很容易伪造请求直接访问未被授权的页面。
编程要求：
l 如果URL 不是公开的，那么必须限制能够访问的授权用户；
l 加强基于用户或角色的访问控制；
l 完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等）；
l 验证你的构架；
l 在每一个层次都使用简单肯定的模型；
l 确保每一层都有一个访问机制；
l 验证你的实现；
l 不能使用自动化的分析工具；
l 确保每个URL 都被外部过滤器或其他机制保护；
l 确保服务器的配置不允许对非授权页面的访问。
3.5. PHP 安全开发要求
3.5.1.变量滥用
PHP-4.1.0 发布的时候建议关闭register_globals，并提供了7 个特殊的数组变量来使用各种变量。对于从GET、POST、COOKIE 等来的变量并不会直接注册成变量，必需通过数组变量来存取。PHP-4.2.0 发布的时候，php.ini默认配置就是register_globals = Off。这使得程序使用PHP 自身初始化的默认值，一般为0，避免了攻击者控制判断变量。
通过以下解决方法实现：
配置文件php.ini 设置register_globals = Off。
要求程序员对作为判断的变量在程序最开始初始化一个值。
3.5.2.文件打开
如非特殊需要，把php 的文件操作限制在Web 目录里面。以下是修改apache