信息系统安全技术规范v1.0

2011-10-01实施

2011-10-01发布

中国联通电子渠道安全技术规范

China Unicom Electronic Channel Security Technical Specification

（V1.0）

QB/CU XXX-XXXX

中国联通公司企业标准

目  次

前言    II

第一章    范围    1

第二章    规范引用性文件    1

第三章    缩略语和术语定义    1

第四章    电子渠道安全技术规范概述    3

4.1    电子渠道安全技术规范范围    3

4.2    电子渠道安全技术规范内容    3

第五章    电子渠道信息系统整体安全技术架构    3

第六章    电子渠道安全技术要求    4

6.1    业务安全    4

6.1.1    登陆办理类    4

6.1.2    信息查询类    5

6.1.3    电子商城类    6

6.1.4    缴费充值类    6

6.1.5    页面展示类    7

6.2    应用安全    7

6.2.1    身份鉴别    7

6.2.2    访问控制    8

6.2.3    入侵防范    9

6.2.4    安全审计    9

6.2.5    剩余信息保护    9

6.2.6    通信完整性    9

6.2.7    通信保密性    9

6.2.8    抗抵赖    10

6.2.9    资源控制    10

6.3    代码安全    10

6.3.1    代码开发    10

6.3.2    代码测试    18

6.3.3    代码部署    19

6.4    数据安全    20

6.4.1    数据保密性    20

6.4.2    数据完整性    20

6.4.3    数据可用性    20

前  言

为了规范中国联通电子渠道系统的安全防护建设，中国联通制定了以下安全规范:

（1）《中国联通电子渠道安全技术规范》

（2）《中国联通电子渠道安全测试规范》

本标准是其中的《中国联通电子渠道安全技术规范》。

本标准是在充分了解中国联通ECS、ESS系统的安全建设情况以及未来规划，参考相关行业标准的基础上，编制而成。

本标准由中国联通公司电子渠道中心提出，并由中国联通公司技术部统一归口管理。

本标准主要起草单位：中国联通公司电子渠道中心。

本标准主要起草人：刘江林、金波、吴盛博、陈晓光、刘宇航等。

本标准的修改和解释权属中国联通公司。

中国联通电子渠道安全技术规范

第一章范围

本规范规定了电子渠道ECS、ESS系统的安全技术规范，适用于中国联通总部电子渠道中心，是中国联通ECS、ESS系统的应用安全技术规范和依据。本规范为总部电子渠道ECS、ESS系统提供安全技术规范。

第二章规范引用性文件

《173-2010中国联通电子渠道技术规范v1.0》

《YD/T 2092-2010 网上营业厅安全防护要求》

《YD/T 1752-2008 支撑网安全防护要求》

《YD/T 1728-2008 电信网和互联网安全防护管理指南》

《YD/T 1729-2008 电信网和互联网安全等级保护实施指南》

《YD/T 1730-2008 电信网和互联网安全风险评估实施指南》

《YD/T 1731-2008 电信网和互联网灾难备份及恢复实施指南》

第三章缩略语和术语定义

本规范所涉及的缩略语定义如下：

4.1电子渠道安全技术规范范围

中国联通电子渠道安全技术规范是围绕中国联通网上营业厅、电子化销售服务管理系统和企业门户三大业务应用，以业务安全、应用安全、代码安全和数据安全为重点，研究和编制符合中国联通电子渠道在线电子商务特点的安全防护技术规范，制定电子渠道信息系统的业务和应用在设计、开发、部署、运行、维护等全生命周期各个环节应满足的安全技术要求。

4.2电子渠道安全技术规范内容

电子渠道安全技术规范主要对子渠道信息系统的应用安全、业务安全、代码安全和数据安全技术防护要求进行阐述。

第五章电子渠道信息系统整体安全技术架构

图 5-1 电子渠道系统安全技术整体技术架构

第六章电子渠道安全技术要求

6.1业务安全

6.1.1登陆办理类

1.电子渠道信息系统应对用户注册过程执行统一的口令策略，包括：

1口令设置者(如:系统颁发或用户自行设置)。

2如果系统必须颁发初始口令，应该避免使用统一的用户初始口令，应强制要求用户在初次登录系统时修改初始口令。

3口令长度。

4口令至少包含的特征组(如：小写字母，数字，大写字母以及特殊符号等)。

5用户不应使用出现在常见列表中的口令类型(如:常见字符、词组、用户名作为密码等)。

2.电子渠道信息系统对于用户自助形式首次注册帐户的激活操作应使用其他方式（如：短信、邮件、手机号绑定、固话号码绑定等）进行确认。 

3.电子渠道信息系统应为注册功能模块设置强验证码机制，防止机器人恶意注册，验证码的抗识别强度要求包括：

1包含的特征组（如：大小写字母、数字组合，去掉歧义字符，0和o、l和1、z和2、q和9。）。

2应采用的算法（如：符号扭曲、粘连算法）。

3应采用的元素（如：字体）的间距不规则分布。

4应加入的干扰元素（如：一条干扰斜线，覆盖所有字符）。

5背景色彩应使用的颜色（如：与网站整体风格一致）。

6后台验证码生成算法应定期更新(建议每3月更新一次)。

7验证码应设置超时时限（如：小于等于5分钟）。

4.电子渠道信息系统帐户注册过程应强制要求用户必填项信息（如：手机号、姓名、身份证号码等），并验证其必填项信息（如：手机号、身份证号码等）以及凭据找回渠道的有效性和真实性（如：邮箱、手机号必须真实且为帐户注册人持有）。

5.电子渠道信息系统应分系统不同制定多因素、多方式的登录认证功能，包括：

1ESS系统应具备多因素认证机制（如：口令+电子钥匙）。

2ECS系统应具备多方式的认证机制（如：手机号/服务密码，手机短信随机密码，用户名/口令）。

6.电子渠道信息系统应为认证功能模块设置强验证码机制，防止恶意暴力破解，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。

7.电子渠道信息系统在用户成功登录后，应将上一次的登录信息（如：登录时间、地点、认证结果等）显示给用户。

8.电子渠道信息系统应禁用“自动登录”或“记住密码”等功能(如:网厅、手机厅)。

9.电子渠道信息系统认证失败的提示内容不应该指明具体错误的部分（如：登录信息错误时都提示“无效的用户名和/或密码”而不是“无效的用户名”或“密码无效”）。

10.应按用户登录电子渠道信息系统的不同方式，实现用户操作功能权限的横向、纵向隔离，不但应保证用户登录后只能访问该用户的相关信息，不能非法访问其它用户相关信息，而且只能实现该方式下运营商开放给用户的系统功能。

11.电子渠道信息系统应对关键业务的办理执行严格的二次认证：

1对于需要手机号绑定的用户账户 (如ECS的网站用户绑定手机号码的操作)，应采用手机短信动态口令验证，并应设置动态口令超时时限为小于或等于1分钟。

2对于不与手机号绑定的用户账户 (如ECS的宽带、小灵通用户等不绑定手机号的账户类型)，应要求其提供可用邮箱地址，并通过邮箱激活邮件验证验证用户身份的真实有效性。

12.电子渠道信息系统应具备严格的防篡改机制，保证业务办理过程中数据的完整性。

13.电子渠道信息系统业务办理类申请应具有二次确认机制，二次确认应采用多种方式进行（如：短信确认、再次点击确认等）。

14.电子渠道信息系统应具备完善的权限控制机制，保障用户在业务办理流程的每一步所具有的权限应受到功能级别细粒度的控制（如：2G用户不能办理3G用户业务）。

15.电子渠道信息系统每个业务办理流程应生成随机业务流水号，防止攻击者猜测标识或依据当前标识推导后续的标识。

16.电子渠道信息系统每个业务办理流程应生成时间戳，防止重放攻击。

17.电子渠道信息系统每个业务办理流程应具备自动退出机制，业务办理过程中，如果用户退出或会话意外中断、超时等情况，应重新进行认证。

18.电子渠道信息系统应为账号的密码重置功能采用二次认证机制。二次认证要求按本规范6.1.1节第11)条执行。

19.电子渠道信息系统服务器端应保证同一业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。

20.电子渠道信息系统客户端页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到业务过程乱序的目的。

21.电子渠道信息系统应具备登陆办理类业务审计（日志）功能，并覆盖到每个用户，对重要业务信息（登录信息、认证结果、业务操作、数据信息、业务结果等）有详细记录。

6.1.2信息查询类

1.电子渠道信息系统应对详单查询操作采取二次认证机制，二次认证要求见“登录办理类”之11)中所示。

2.应按用户登录电子渠道信息系统的不同方式，实现用户详单查询操作功能权限的横向、纵向隔离，权限隔离按本规范6.1.1节第10)条执行。

3.电子渠道信息系统应为查询类功能提供强验证码机制，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。

4.电子渠道信息系统应对涉及用户隐私的查询类功能(如：详单查询)采用基于手机短信动态口令验证的二次认证机制。该类查询功能成功后应进行短信通知。

5.电子渠道信息系统应对查询频率进行。

6.电子渠道信息系统应对信息查询类业务需要接纳用户输入的数据接口，添加针对输入数据的符合性进行验证。(如身份证输入框，应对输入的字符种类和长度做相应合法性验证，过滤有害字符)。

7.电子渠道信息系统服务器端应保证同一详单查询业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。

8.电子渠道信息系统页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到实现业务过程乱序的目的。

9.电子渠道信息系统应具备信息查询类业务审计（日志）功能，并覆盖到每个用户，对重要详单查询行为（用户信息、查询操作、认证结果、查询字段等）有详细记录。

10.电子渠道信息系统信息查询类日志记录内容中不应包含应用系统非必须的敏感信息（如：身份证号码、信用卡信息、通话详单、短信详单等）。

6.1.3电子商城类

1.电子渠道信息系统应具备完善的权限控制机制，保障用户在商城购物流程的每一步都应查询其当前认证状态，并严格检查其权限。

2.电子渠道信息系统商城业务流程中各个数据交互环节，如果存在会对后续流程环节内容有影响的操作，应存在防篡改机制，对必须从客户端获取的参数采用加密传输机制，并在服务器端对该类参数进行合法性验证，使得业务流程设计时设定为不应篡改的数据（如：表示商品种类、金额、积分额度、付款状态等参数）其完整性得到保证。

3.电子渠道信息系统应为电子商城类交易功能提供强验证码机制，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。

4.电子渠道信息系统每个商城交易流程应生成随机订单号，防止攻击者猜测标识或依据当前标识推导后续的标识。

5.电子渠道信息系统应对单个订单交易额度以及单个用户交易频率进行控制（防止洗钱行为）。

6.电子渠道信息系统应对积分兑换行为进行二次认证，积分兑换成功后应进行短信通知。

7.电子渠道信息系统客户端应对电子商城类业务中需要接纳用户输入的数据接口，添加针对输入数据的合法性进行验证(如：身份证输入框，应对输入的字符种类和长度做相应合法性验证，过滤有害字符)。

8.电子渠道信息系统电子商城类模块应对第三方系统接口数据进行加密传输，以保障交易数据的机密性。

9.电子渠道信息系统电子商城类模块应对第三方系统接口数据附加数字摘要，以保障交易数据的完整性。

10.电子渠道信息系统电子商城类交易中，虚拟商品（如：充值卡）交易应记录强类型用户身份关联信息（如：手机号、身份证、姓名等）。

11.电子渠道信息系统应对电子商城交易类业务中被具体交易过程锁定的被购买商品(如：手机号，上网卡等)设定超时时限，对于长时间未交易成功的订单对应的被购买商品进行自动释放。

12.电子渠道信息系统客户端页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到实现业务过程乱序的目的。

13.电子渠道信息系统服务器端应保证同一商城购物业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。

14.电子渠道信息系统应具备电子商城类业务审计（日志）功能，并覆盖到每个用户，对重要交易信息（用户信息、交易操作、交易物品、金额、积分额度、付款状态、付款方式等）有详细记录。

15.审计记录内容中不应包含应用系统非必须的交易信息（如：充值卡卡密、信用卡信息）。

16.电子渠道信息系统应具备电子商城类交易账目对账机制，定期核对交易账目收支情况。

6.1.4缴费充值类

1.电子渠道信息系统应为缴费充值类交易功能提供强验证码机制，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。

2.电子渠道信息系统缴费充值类业务流程中各个数据交互环节，如果存在会对后续流程环节内容有影响的操作，应存在防篡改机制，对必须从客户端获取的参数采用加密传输机制，并在服务器端对该类参数进行合法性验证，使得业务流程设计时设定为不应篡改的数据（如：缴费金额、充值卡金额，折扣率等参数）其完整性得到保证。

3.电子渠道信息系统应对单个交易（如：购卡、充值、缴费等）额度以及单个用户交易频率进行控制（防止洗钱行为）。

4.电子渠道信息系统缴费充值类页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到实现业务过程乱序的目的。

5.电子渠道信息系统缴费充值类模块应对第三方系统接口数据进行加密传输，以保障交易数据的机密性。

6.电子渠道信息系统缴费充值类模块应对第三方系统接口数据附加数字摘要，以保障交易数据的完整性。

7.电子渠道信息系统缴费充值类交易中，虚拟商品（如：充值卡）交易应记录强类型用户身份关联信息（如：手机号、身份证、姓名等）。

8.电子渠道信息系统应提供必要的校验措施（如：设置充值卡密状态标志），实现当卡密处于非激活状态时，即使外部人员成功猜测并构造了充值卡密也无法通过系统校验，从而无法成功的进行充值。

9.电子渠道信息系统应具备足够的审计措施，实现对内部人员使用内部系统接口伪造缴费请求（如：直接对目标手机卡进行充值）等行为的监控，并设定交易账目对账机制，定期核对交易账目收支情况。

10.电子渠道信息系统服务器端应保证同一缴费充值业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。

11.电子渠道信息系统应对缴费充值类业务中被具体交易过程锁定的被购买商品(如：充值卡等)设定超时时限，对于长时间未交易成功的订单对应的被购买商品进行自动释放。

12.电子渠道信息系统应具备缴费充值类业务审计（日志）功能，并覆盖到每个用户，对重要交易信息（用户信息、交易操作、交易物品、数量、折扣率、金额、积分额度、付款状态、卡密提取状态、付款方式等）有详细记录。

13.审计记录内容中不应包含应用系统非必须的交易信息（如：充值卡卡密、信用卡信息）。

14.电子渠道信息系统应具备缴费充值类交易账目对账机制，定期核对交易账目收支情况。

6.1.5页面展示类

1.电子渠道信息系统展示类业务应提供必要的保障机制，保证向用户展示信息（如：套餐资费、优惠活动）的正确性。

2.电子渠道信息系统展示类业务应提供必要的保障机制，保证非业务数据不应被呈现。

3.电子渠道信息系统展示类业务应提供必要的保障机制，保证用户预留信息被正确展示。

4.电子渠道信息系统应每页最大显示查询结果条目数量。

6.2应用安全

6.2.1身份鉴别

6.2.1.1身份标识和鉴别

1.应提供专用的登录控制模块对登录电子渠道信息系统的用户进行身份标识和鉴别。

2.应提供登录电子渠道信息系统用户身份标识的唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用。

3.除登录密码外还应支持图片验证码或其它预防暴力猜测帐号密码的措施。

4.电子渠道信息系统应采用随机数生成图片验证码，严禁以任何形式配置可反复通过系统验证的万能验证码。

5.应在图片验证码图片背景中插入噪点、干扰（如：斜线干扰、字体大小随机、字体位置分布不均匀等）。

6.对于无需登录的业务（如：购卡）应采用一次性短信或邮件验证码机制。

7.会话标识必须足够随机，防止攻击者猜测标识或依据当前标识推导后续的标识。

8.用户登录后必须分配新的会话标识，不能继续使用用户未登录前所使用的标识。

9.认证失败提示中不应指明具体失败的原因或字段，比如，应使用“无效的用户名或密码”来代替“无效的用户名”或“密码错误”。

6.2.1.2密码设置策略

1.电子渠道信息系统应具有密码复杂度判断和提示机制，能够判断及显示用户当前密码的安全性等级，当用户密码存在风险时应能够提示用户进行修改。

6.2.1.3登录

1.应设置连续登陆失败次数阈值，一定时间内登录失败次数超过阈值应自动锁定账号。

2.应启用登录失败处理功能，可采取结束会话和自动退出等措施。

6.2.1.4远程访问

1.应对重要电子渠道信息系统重要模块（如：管理门户）的访问进行加密，如采用https协议替代http协议。

6.2.1.5登录警示

1.电子渠道信息系统应设置鉴别警示信息，当发现并阻止用户试图越权访问信息的行为时，应进行提示并描述未授权访问可能导致的后果。

6.2.2访问控制

6.2.2.1通信控制

1.应对从互联网进入电子渠道信息系统的流量进行过滤，实现对应用层HTTP协议命令级的控制。

2.电子渠道信息系统应具备会话超时机制，用户通过互联网与电子渠道信息系统Web服务器建立的会话处于非活跃一定时间后，电子渠道信息系统Web服务器设备应自动终止会话。

3.如果电子渠道信息系统启用了SSL加密，其版本应不低于3.0。

4.电子渠道信息系统不应将SSL设置为可选的方案，不应在使用443端口（SSL通信端口）的同时也接受80端口（一般的HTTP服务端口）请求，不应允许用户选择安全级别。

6.2.2.2帐户管理

1.应至少6个月进行一次对管理账户的回顾检查，确认每个管理帐号的使用人员。

2.应默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令。

3.应及时删除多余的、过期的帐户，避免共享帐户的存在。

4.应根据电子渠道信息系统管理账户的角色分配权限，实现管理账户的权限分离，仅授予管理账户所需的最小权限。

6.2.2.3敏感标记

1.应对重要信息资源（如：充值卡密、个人信息等）设置敏感标记。

2.应依据安全策略严格控制用户对具有敏感标记的重要信息资源所进行的操作。

6.2.3入侵防范

1.直接面向互联网为用户提供服务的电子渠道信息系统设备（如Web服务器设备）仅开放为登录电子渠道信息系统用户提供服务所必须的服务端口（如HTTP、HTTPS 对应端口及向BSS系统开放的端口），并采用技术手段监控端口通信情况。

2.电子渠道信息系统功能模块应遵循最小建设原则，仅建设必要的组件和功能模块。

3.应在电子渠道信息系统与互联网的网络边界处部署IDS或IPS设备，检测、防御以下攻击行为：端口扫描、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP碎片攻击和网络蠕虫攻击等。

4.应能够检测到对电子渠道信息系统中主机进行入侵的行为，能够记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间，并在发生严重入侵事件时进行告警。

6.2.4安全审计

6.2.4.1审记建立

1.应对电子渠道信息系统重要安全事件（如：攻击行为、非法操作等）进行审计。

6.2.4.2审记记录

1.应提供覆盖到电子渠道信息系统每个用户的安全审计功能。 

2.应对电子渠道信息系统用户的登录过程进行审计。

3.应对电子渠道信息系统重要页面（购卡、充值、付款）操作进行审计。

4.审计记录的内容应至少包括事件日期、时间、发起者信息、类型、描述和结果等。

5.审计记录内容中不应包含应用系统非必须的用户身份信息（如：身份证号码）。

6.审计记录内容中不应包含应用系统非必须的交易信息（如：充值卡卡密、信用卡信息）。

6.2.4.3审计管理

1.应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。

2.应保护审计进程，避免受到未预期的中断。

3.应保证无法删除、修改或覆盖审计记录。

4.应采用技术手段（如：定期运行文件完整性监控软件），能够发现应用系统关键数据或文件被非授权更改并通知相关人员，应至少每周对关键文件进行比较。

6.2.5剩余信息保护

1.应采用技术手段保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除，无论这些信息是存放在硬盘上还是在内存中。

2.应采用技术手段保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除。

6.2.6通信完整性

1.应采用约定通信会话方式的方法保证通信过程中数据的完整性。

6.2.7通信保密性

1.在通信双方建立连接之前，电子渠道信息系统应利用密码技术进行会话初始化验证。

2.应对通信过程中的敏感信息字段（如：充值卡密、个人信息等）进行加密。

6.2.8抗抵赖

1.电子渠道信息系统应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能。

6.2.9资源控制

1.电子渠道信息系统应提供访问控制功能控制用户组/用户对系统功能和用户数据的访问。

2.电子渠道信息系统应配置访问控制策略，并严格默认用户的访问权限。

3.访问控制的覆盖范围应包括与资源访问相关的用户、信息及它们之间的操作。

4.应能够对单个用户帐户的多重并发会话进行。

5.应能够对一个时间段内可能的并发会话连接数进行。

6.当用户无效登陆次数超过阈值（如：5次），应对账户进行锁定，且锁定时间应当足以阻止暴力的凭据猜测（如：30分钟）。

7.应能够对一个访问帐户或一个请求进程占用的资源分配最大限额和最小限额。

8.应能够对系统服务水平降低到预先规定的最小值进行检测和报警。

9.应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话。

6.3代码安全

6.3.1代码开发

6.3.1.1通用规则

1.电子渠道信息系统应确保开发环境与生产运行环境间具备隔离措施。

2.电子渠道信息系统应对来自客户端的重要数据（如：用户信息、交易操作、交易物品、数量、折扣率、金额、积分额度、付款状态、卡密提取状态、付款方式等）进行认证，包括那些不容易被客户修改的值（如cookies，隐藏域）。

3.电子渠道信息系统程序的逻辑处理与验证不应依赖访问请求到达的顺序，防止攻击者随意控制访问请求到达的顺序来适合自己的需要，（如：程序通过不同页面来搜集信息，在较早的表单里验证了信息，而在修改信息的表单则没有进行验证，那么攻击者就可以利用后者来绕过输入验证）。

6.3.1.2输入验证

1.电子渠道信息系统应对所有数据来源的可信度进行分类（如：可信/非可信），要求在程序中定义清晰的可信边界，代码中用于保存可信数据（如：服务器端数据）的数据结构，不能被用来存储不可信（如：客户端、网络端）数据。

2.电子渠道信息系统应对所有属于非可信类别数据源进行验证（如：用户输入、客户端文件流等），不能通过验证的数据将会被拒绝或丢弃，以确保在输入验证之前，输入的数据不能进入程序代码中被执行。

3.电子渠道信息系统应维护一个可信的边界，不可信数据应单独存放在专门存放不可信数据的数据结构内，在经过验证之后才被放在可信区域。

4.电子渠道信息系统收到无法处理的或错误的输入应进行统一的失败控制，默认策略应对输入进行拒绝或丢弃。

5.电子渠道信息系统应拒绝所有验证失败的输入行为，不应试图修复一个未能通过输入验证的数据请求，应直接拒绝掉该请求。

6.电子渠道信息系统应对所有由客户端提交的数据在处理前进行检查，包括所有的参数、URL、HTTP头内容（如：Cookie，Get，Post，Referr）、JavaScript、Flash、或其他的嵌入代码。

7.电子渠道信息系统应对来源于网络的数据进行校验，保证数据包的大小和内容都是与预期要求相符的，这些威胁体现在网络通信的一切行为中（如：从DNS返回的信息可能被假冒，数据包中非负荷数据也可能被伪造，攻击者可以专门构造数据包用于进行某些攻击等等）。

8.电子渠道信息系统应确保请求和响应头中的值仅包含ASCII字符。

9.电子渠道信息系统应避免通过用户控制的参数来重定向或包含另外一个网站的内容。

10.电子渠道信息系统应验证输入数据类型是否合规。

11.电子渠道信息系统应验证输入数组范围是否合规。

12.电子渠道信息系统应验证整数输入的边界值是否合规。

13.电子渠道信息系统应验证输入数据长度是否合规，验证时，应该检查输入的最小和最大长度。

14.电子渠道信息系统中应对输入中的危险字符进行过滤，常见的危险字符包括：

1‘|’（竖线符号）。

2‘&’（& 符号）。

3‘;’（分号）。

4‘$’（美元符号）。

5‘%’（百分比符号）。

6‘@’（at 符号）。

7‘ '’（单引号）。

8‘"’（引号）。

9‘\\'’（反斜杠转义单引号）。

10‘\\"’（反斜杠转义引号）。

11‘<>’（尖括号、‘()’（括号）。

12‘+’（加号）。

13‘CR’（回车符，ASCII 0x0d）。

14‘LF’（换行，ASCII 0x0a）。

15‘,’（逗号）。

16‘\’（反斜杠）。

15.电子渠道信息系统中应对变种输入进行过滤，常见的变种输入包括：

1空字节(%00)。

2换行符(%0d, %0a, \\r, \\n)。

3反斜线和点(../ 或 ..\以及 %c0%ae%c0%ae/)。

6.3.1.3输出验证

1.电子渠道信息系统中对来源于外部的数据（包括用户输入、文件、网络、数据库等）输出时，应对输出信息进行转义，过滤其中的元字符，从而阻止输出的数据中夹带的恶意代码（例如XSS攻击）对终端用户的威胁。

6.3.1.4认证及密码管理：

1.电子渠道信息系统应对所有网页和资源的访问进行身份认证，除了设定为对公众开放的资源（如：网厅首页）。

2.电子渠道信息系统的所有身份认证过程应在可信系统上进行（如：服务器端），防止攻击者绕过请求页面和浏览器，直接与应用服务器进行通信（如：不应使用JavaScript的验证逻辑，JavaScript可以帮助合法的用户对不正常的输入信息进行检测，但是不能确保服务器接收到数据的安全性）。

3.电子渠道信息系统应拒绝所有认证失败的访问并提示错误。

4.电子渠道信息系统应采用足够强度添加随机值的单向哈希算法来保证密匙和凭据的存储（应尽量避免使用MD5算法），同时，应只能通过电子渠道信息系统能够对存储密码的表或文件进行写操作。

5.电子渠道信息系统的所有密匙和凭据哈希过程应当在可信系统上进行（如：服务器端）。

6.电子渠道信息系统的身份认证过程，应仅在完成所有的认证信息（如：密匙和凭据）输入后才开始。

7.电子渠道信息系统应采用统一的口令策略，包括：

1用户应自己设置口令。

2如果系统必须颁发初始口令，应该避免使用统一的用户初始口令，应强制要求用户在初次登录系统时修改初始口令。

3口令必须包含至少6个字符。

4口令至少包含2个特征组：小写字母，数字，大写字母以及特殊符号（服务密码除外）。

5用户不应使用出现在常见列表中的口令。

6用户不应使用与其用户名类似的口令。

8.电子渠道信息系统认证失败的提示内容不应该指明具体错误的部分（如：登录信息错误时都提示“无效的用户名和/或密码”而不是“无效的用户名”或“密码无效”）。

9.应使用安全的方法存储口令，包括：

1不应明文存储口令。

2口令在存储前应通过安全的单向hash函数转化为不可还原的形式。

3不应在通信内容中包含口令。

4不应在错误信息中包含口令。

10.电子渠道信息系统应对与涉及敏感信息（如:卡密、详单等）或功能的外部系统（如：BSS）连接进行二次认证（如：手机短信动态口令验证）。

11.电子渠道信息系统应使用安全的方法进行口令找回，包括：

12.应通过邮箱、短信形式发送临时验证码，通过临时验证码验证后，设置新密码。

13.电子渠道信息系统应只使用HTTP POST请求发送身份验证凭据。

14.电子渠道信息系统应采用加密连接或数据加密发送认证信息（如:密匙和凭据）。

15.电子渠道信息系统各个身份验证页面，应使用相同位数的同一特殊字符（如：*和#）代替以明文方式显示密码（如：服务密码）。

16.电子渠道信息系统帐户注册过程应验证其凭据找回渠道的有效性和真实性（如：邮箱、手机号必须真实且为帐户注册人持有）。

17.电子渠道信息系统帐户密码的更改及重新设定，应具备二次认证机制。其安全控制措施不应少于帐户的注册及认证。

18.应使用其它方式确认并通知用户信息的修改，包括：

1应在用户改变其帐号信息时（如修改口令或者重置口令），对当前用户口令进行校验。

2应要求用户通过email等方式来确认其改变的行为。

3不应在确认邮件中包含认证信息。

4当用户改变其联系信息时，应将改变通知同时发送给旧的email地址和新的email地址。

19.电子渠道信息系统应执行口令重置策略，包括：

1口令重置应是一个自动过程，在正常操作流程下，不应有人为的干涉。

2用户应在其第一次创建口令的时候建立一个安全问题以及对应的答案。

3如果用户的身份不能通过用户名、安全问题以及答案来确定，用户应提供其身份的证明。

20.电子渠道信息系统帐户密码的更改及重新设定操作如果使用基于短信或电子邮件的复位，应只发送含有一个临时的验证码的短信或电子邮件至预先登记的邮件地址。

21.电子渠道信息系统帐户的临时验证码，应设置一个短的过期时限（如：5分钟）。

22.当用户帐户发生密码重置或修改行为，应及时通知用户（如：短信或邮件）。

23.电子渠道信息系统应禁用“自动登录”或“记住密码”等功能。

24.电子渠道信息系统应将用户预留信息（防钓鱼），在用户登录成功后进行提示。

25.电子渠道信息系统应将用户最后一次登陆帐户的结果（如：成功或不成功），在用户下一次登录成功后进行提示。

26.电子渠道信息系统应对开发过程中内置默认帐户或密码的通信采用加密机制。

6.3.1.5会话管理:

1.电子渠道信息系统应使用会话管理控制程序，系统应只响应被控制程序标识为有效的会话。

2.创建会话标识符的过程应始终在可信任的系统上进行（如：服务器端）

3.会话标识必须足够随机，防止攻击者猜测标识或依据当前标识推导后续的标识，应使用一种生成代价小并满足安全需求的随机数生成方法来生成应用程序需要的随机数，目前有如下三类生成方案：

1不安全的随机数生成器，这是一种非密码学的伪随机数生成器，攻击者可以知道生成器能够输出的数值。

2密码学的伪随机数生成器，这是一种使用一个单一的安全种子来产生许多不可猜测的随机数的方法，该方案在多数情况下是安全的，最重要的是其使用的安全种子。

3信息熵收集器，该方案在一些时候是“真正的”随机数生成器，其主要工作是收集来自其它源以及自身的信息熵。但是其产生数据的速度过慢。

根据以上方案具体要求如下：

1不应使用不安全的随机数生成器。

2应使用信息熵作为密码学伪随机数生成器的种子，但在生成长期的密钥的情况下，不使用这种方法。

3若需要相同的数据流，就不能修改生成器的种子，因为在使用固定的种子时密码学伪随机数生成的输出流也是固定的。

4使用能够获取好的随机数的方案。不应使用熵很低或容易被猜到的种子，例如时间、日期或空种子。

5在Java中，使用SecureRandom类，不要使用Random类，SecureRandom类的默认构造方法可以正确选种，Java会自动获取一个信息熵比较平均的值。

6最好使用硬件的随机数生成器，要求其在没有收集到足够的真实随机序列来生成种子时，就会中断。如果使用的是不会中断的，要求在使用之前仔细测试是否有足够的种子。

7使用操作系统或者其使用的加密库的一个真实的随机源

8在Unix平台上，从/dev/urandom读取16字节可以给出相当高质量的随机序列。

9在Linux中，/dev/urandom是不中断的，并且总会返回请求的字节数，但/dev/random在没有足够的真实随机序列时则会中断。

4.用户登录后必须分配新的会话标识，不能继续使用用户未登录前所使用的标识。

5.用户退出登陆后应完全终止相关的会话或连接。

6.所有被身份认证机制保护页面都应提供账户退出功能。

7.电子渠道信息系统会话ID长度不应低于位，建议使用128位长度的会话ID

8.在确定会话ID的长度以及生成ID的随机种子之前，不应相信web程序的容器，因为会话ID太短很容易被暴力猜解，如果攻击者能猜到授权用户的会话ID就可以接管用户的会话。

9.电子渠道信息系统应禁止相同的用户ID同时登录。

10.不应在url中显示会话标识符、错误信息或日志，会话标识符应只包含于HTTP cookie头中（如:不应通过GET参数传递会话标识符）。

11.电子渠道信息系统应采用实施适当的访问控制措施，防止服务器上的其他用户未经授权访问服务器端的会话数据。

12.电子渠道信息系统应规定一个会话最大空闲时间，具体要求如下：

1应强制执行一个会话最大空闲时间，建议将超时时间设置为小于30分钟以缩短那些未能及时注销的用户暴露在外的时间，减少可供攻击者猜解的会话ID平均数目。

2应将应用程序框架将会话最大空闲时间设置为可配置的参数，并提示相关人员如何进行正确的设置。

13.电子渠道信息系统应允许用户主动注销或结束当前会话。

6.3.1.6访问控制

1.电子渠道信息系统应只有授权的用户能访问受保护的URL（如：系统管理界面）。

2.电子渠道信息系统应只有授权的用户能访问受保护的功能（如：系统管理功能）。

3.电子渠道信息系统应只有授权的用户能引用受保护的对象（如：系统内部接口）。

4.电子渠道信息系统应只有授权的用户能引用受保护的接入服务。

5.电子渠道信息系统应只有授权的用户能引用受保护的应用数据。

6.电子渠道信息系统应对用于访问控制的相关数据和策略的访问和操作。

7.电子渠道信息系统应只有授权的用户能访问安全相关的配置信息。

8."referer"头应只作为辅助检查手段，不应作为唯一授权检查手段。

9.电子渠道信息系统应定期重新验证用户的授权，以确保其权限没有改变，对于所有的权限变更行为，应注销登陆，并迫使用户重新进行认证。

10.电子渠道信息系统应支持当授权终止时自动锁定帐户及终止当前会话（如：角色变更、权限变更、策略变更、业务流程变更等）。

11.电子渠道信息系统应对文件系统进行访问控制，具体要求如下：

1文件只能被指定的用户访问，并且该用户的权限被为最小权限。

2当应用程序使用被其控制的已存在文件时，必须首先验证是否存在防止文件被篡改的许可权限，并且不能将许可权限的管理交给系统管理员一个人处理。

3为了安全的使用临时文件，要求在程序初始化时创建一个只能被该程序读写的文件夹，不能将该文件夹放在用户可访问到的地方，并将所有的临时文件都放在其中，这样就可以防止攻击者猜测被使用的临时文件的名字，提前创建该文件来进行内容操纵或者拒绝服务攻击。

12.电子渠道信息系统应建立文件访问竞争条件，具体要求如下：

1确保在程序对某文件进行一系列操作之后，不应能被替换或者修改，在C语言中，避免使用操作文件名的函数，应该首先打开该文件获得文件句柄，然后通过使用操作文件句柄的函数来进行操作，因为不能够保证在函数调用域之外的空间上，它指向的仍是硬盘上同一文件。

2当用户可以访问本地文件时，不应使用Java来实现具有特定权限的程序，因为在Java中，虚拟机对文件的操作是基于路径的，而不是操作系统的文件句柄的，所以文件访问竞争条件是不可避免的。

13.电子渠道信息系统应使用验证码以防止恶意登陆、破解尝试行为，验证码的抗识别强度应按照如下要求：

1为方便用户肉眼辨认，应采用大小写字母、数字组合，去掉歧义字符，0和o、l和1、z和2、q和9。

2应采用符号扭曲、粘连算法。

3应采用字体间距不规则分布。

4应加入一条干扰斜线，覆盖所有字符。

5背景色彩应使用与网站整体风格一致的颜色。

6后台验证码生成算法应定期更新(建议每3月更新一次)。

7验证码超时时限应小于等于5分钟。

6.3.1.7数据加密

1.电子渠道信息系统中所有涉及敏感信息（如：卡密、详单、个人信息）的加密过程应始终在可信任的系统上进行（如：服务器端）。

2.电子渠道信息系统应建立和执行加密凭据管理流程。

3.电子渠道信息系统应减小无用隐私信息的存活时间，保存隐私信息的时间应尽量的短（如：在认证后，不允许保留用户口令，包括在内存里），要求高安全级别的系统锁定内存分页，防止操作系统将这些数据缓存到磁盘的交换文件中。

4.电子渠道信息系统应尽量少的共享私密信息，不允许在客户端长期保存秘密信息，在选择了数据发送到客户端的时候，要假设任何通过客户端共享的数据都是不安全的。

6.3.1.8错误处理

1.电子渠道信息系统不应在错误响应中携带敏感信息，包括系统的详细信息、会话标识符及帐户信息。

2.电子渠道信息系统应使用不显示调试或堆栈跟踪信息的错误处理程序。

3.电子渠道信息系统应采用通用的错误提示信息，并为HTTP错误建立一个默认的错误页面，丢弃掉所有的异常，防止攻击者从应用程序的默认出错页面中得到系统信息。

4.电子渠道信息系统应构造错误提示信息来防止诸如用户id、网络、应用程序以及服务器环境的细节等重要的敏感信息的泄漏。包括：

1不应采用Web容器自身的错误信息页面。

2在返回的错误信息中不应包含主机信息、网络信息、DNS信息、软件版本信息、错误代码或者其它发生的错误的详细信息。

3不应把错误的细节放在错误页面的注释里。

5.电子渠道信息系统自身应具备处理应用程序错误的能力，不应依赖于服务器的配置处理异常和错误。

6.电子渠道信息系统应当错误情况发生时正确释放已分配的内存空间。

7.错误处理流程应与访问控制策略结合，错误处理默认策略应当拒绝默认访问。

6.3.1.9日志记录

1.错误处理日志记录过程应始终在在可信任的系统上进行（如：服务器端），并严格对日志记录的访问控制。

2.日志记录应同时支持对指定事件（登陆、详单查询、业务办理、充值、购卡、商城购物、积分兑换等）结果的成功和失败进行记录。

3.电子渠道信息系统应确保日志条目中如果存在非信任数据（如：记录用户输入的内容）不能作为代码被执行。

4.电子渠道信息系统应只有授权用户具有访问日志的权限。

5.电子渠道信息系统日志记录内容中不应包含应用系统非必须的敏感信息（如：身份证号码、信用卡信息）。

6.电子渠道信息系统应在日志中使用时间戳，因为日志重新创建了一个已发生事件的队列，在多线程或者分布式系统，时间戳可以清晰的反映出事件发生的时间队列。

7.电子渠道信息系统应使用一个集中化的日志记录模块，避免使用System.out.println和 System.err.println等异构日志。

8.电子渠道信息系统应具备便于进行日志审计的输出格式，包括：

1应具备审计（日志）功能，并覆盖到每个用户，对重要安全事件（系统管理、用户管理、授权管理、重要业务操作等）有详细记录。

2审计（日志）的字段要完整。

3审计（日志）数据可读性强。

4审计（日志）数据的访问控制要合理，避免未授权访问。

5应合理划分业务系统管理权限、审计管理权限、普通业务操作权限用户权限。

9.电子渠道信息系统应创建清晰的日志等级，包括：

1应日志等级明确、不交叠，并且在整个系统中只存在一个日志级别。

2应在定义或者选择了一个日志级别时，保证系统会使用规定好的日志级别，当系统正在进行不同类别的操作时，确保日志等级在特殊场景下可以正确响应。

3日志状态应分组存储到清晰定义的日志等级中，这样有助于理解日志的含义，确保一个统一的系统映像被反映到日志中。

10.电子渠道信息系统应建立记录日志的原则，包括：

1保证一致的日志记录，其有助于确保查询结果的正确性。

2保证每一种日志级别都能被使用且能避免被错误地使用，（如：DEBUG级日志不能出现在系统中）。

11.电子渠道信息系统应对所有登陆失败尝试行为记录日志。

12.电子渠道信息系统应对所有访问控制失败事件记录日志。

13.电子渠道信息系统应记录所有明显的篡改事件，包括标记状态的参数意外变化。

14.电子渠道信息系统应对尝试使用无效或过期的会话令牌的行为记录日志。

15.电子渠道信息系统应对所有应用程序抛出的异常进行日志记录。

16.电子渠道信息系统应对所有系统管理功能、安全功能的变更记录日志。

17.电子渠道信息系统应对加密模块异常或失败记录日志

18.电子渠道信息系统应采用加密哈希函数来验证日志条目的完整性。

6.3.1.10数据保护

1.电子渠道信息系统应在业务流程完成后及时清除包含敏感数据的临时文件或缓存数据。

2.电子渠道信息系统不应将密码、连接字符串及敏感信息以明文或其他非安全加密的方式（嵌入MS SQL视图，Adobe Flash或编译的代码）在客户端存储。

3.电子渠道信息系统应将用户可访问的代码（前端页面）中可能揭示后端系统或敏感信息的注释删除。

4.电子渠道信息系统不应在HTTP GET请求参数中包含未加密的敏感信息（如：卡密、详单、个人信息）。

5.电子渠道信息系统应禁用任何形式的表单填写自动完成功能。

6.电子渠道信息系统应对包含敏感信息的页面禁用客户端缓存，可结合在HTTP标头的"Pragma: no-cache"参数进行控制。

7.电子渠道信息系统应对服务器上存储的敏感数据、缓存和临时文件实施恰当的访问控制措施，只能由授权用户进行访问。

8.电子渠道信息系统应避免用户隐私信息的暴露，包括：

1应在隐私数据出现以前将其清除。确保当安全和隐私冲突时，隐私的优先级高于安全的优先级。

2应根据最小权限原则，将访问隐私数据的权限被在尽可能小的用户组中。

3不应在非必要的情况下传播隐私数据。

9.应在用户间建立强的边界，包括：

1应防止会话中的成员变量泄漏到其它会话或对象中（如：Servlet以及共享池的对象）。

2不应依靠“秘密”值来保护会话信息（如：一个只为单一用户提供的隐藏的URL）。

3设计系统时不应泄漏私有数据，包括在出现异常行为的情况下。

6.3.1.11数据库交互

1.电子渠道信息系统应使用强类型的参数化查询，包括：

1开发者在构造SQL请求时，应明确区分数据部分和命令部分。

2要正确的使用参数化的SQL语句，不允许数据指向改变的方法。

3在要求用户输入影响SQL语句结构的情况下，增加一个动态约束（如：where子句中），不能把用户的输入作为请求语句的一部分。

2.电子渠道信息系统应确保变量是强类型的。

3.使用行级别的访问控制：

1应通过行级别的访问控制来防止用户信息泄露，SQL请求只向当前认证过的用户返回结果。

2应对数据库语句自身进行访问控制，这样攻击者就很难越过这个。

3连接数据库所用的帐号授权遵循最小权限原则，避免使用数据库默认的管理员帐号、高权限帐号。

4.电子渠道信息系统的应用程序访问数据库时，应使用尽可能低的权限。

5.电子渠道信息系统应用程序不应相信来自数据库中的数据，包括：

1验证来自数据库的数据，要对来自数据库的数据进行验证，确保其格式正确且能够安全的使用，不能盲目的信赖数据库。

2要求返回的单值数据在一行出现，如果存在多行很可能被攻击者插入了注入语句，而数据库的单值约束很可能不起作用。

3使用安全可信的内容，要使用安全可信的内容，不能使用具有恶意的信息（如常用系统或者浏览器的关键字），如果出现了这样的字符，就说明攻击者很可能已经成功地越过了输入验证，正在试图发动注入或者跨站脚本攻击。

6.电子渠道信息系统应采用数字证书对数据库的访问进行认证。

7.电子渠道信息系统连接字符串不应在应用程序中进行硬编码，应加密储存在服务器端单独的配置文件中。

8.电子渠道信息系统应在对数据库的访问结束后立即关闭连接。

9.电子渠道信息系统应建立一个资源管理模块并且完全按照规则对资源进行操作，不能依赖Java和.NET的垃圾回收器来回收资源，垃圾回收器在进行回收之前还要检测对象是否适合进行垃圾回收，除非虚拟机的内存已经很低，才会进行垃圾回收，这样无法保证即将被回收的对象是处于正常的状态。

6.3.1.12文件管理

1.电子渠道信息系统不应直接将由用户提供的未经过校验的数据传递给包含动态功能的函数或程序。

2.电子渠道信息系统所有文件上传行为应进行身份认证。

3.电子渠道信息系统应严格文件上传的类型。

4.电子渠道信息系统应通过文件头来判断上传文件类型，不应通过文件扩展名来判断上传文件类型。

5.电子渠道信息系统不应相信文件名或文件内容：

1应对来自文件系统的所有值都进行合适的输入验证，因为文件的大小和名字很难保证是未经篡改的（如：在C/C++中，开发者经常会错误地认为Windows系统的变量MAX_PATH以及Unix/Linux系统的变量PATH_MAX可以在文件系统中出现的最大路径的长度，而这些变量的实际作用是传递给某些操作的最大路径，而在系统中是可以存在更大的路径的）。

2在C/C++中，经常会出现过长的文件名导致的缓冲区溢出，除去这种过长的路径名的风险，根据操作系统的不同，某些操作系统中正常的文件名还可能包含在其它系统中作为关键字的字符。

6.电子渠道信息系统应取消文件上传目录的执行权限。

7.电子渠道信息系统不应将绝对路径传递给客户端。

8.电子渠道信息系统应确保应用程序文件和资源为只读权限。

9.电子渠道信息系统应对扫描用户上传文件进行恶意代码扫描。

6.3.1.13内存管理

1.电子渠道信息系统应对缓冲区大小与其声称值一致性进行二次核对。

2.电子渠道信息系统在编写函数时应采取一定措施避免缓冲区溢出，包括：

1要求代码传递缓冲区的长度。

2探测内存。

3.电子渠道信息系统应进行严格的缓冲区边界检查。

4.电子渠道信息系统应将所有传递给复制和串联类函数的参数截断到指定长度后再进行传递。

5.电子渠道信息系统的资源释放不应依赖于垃圾回收机制（如：连接对象，文件处理等）。

6.电子渠道信息系统应避免使用已知的危险函数（如:printf，strcat，strcpy等）。

6.3.2代码测试

1.电子渠道信息系统应建立检测程序，对系统代码进行安全性测试验收。

2.电子渠道信息系统应提供与生产环境一致的测试环境进行代码安全性测试。

3.电子渠道信息系统在测试验收前应根据设计方案或合同要求等制订测试验收方案，在测试验收过程中应详细记录测试验收结果，并形成测试验收报告。

4.电子渠道信息系统应对系统代码进行的安全性测试验收，包括审查系统使用端口通信情况是否符合系统说明、使用网络侦听工具审查通讯数据包是否符合系统说明和使用恶意代码软件检测软件包中可能存在的恶意代码等。

5.电子渠道信息系统上线前或升级后，应进行对电子渠道信息系统进行代码审核，形成报告，并对审核出的问题进行代码升级完善。

6.电子渠道信息系统应对系统代码进行缓冲区溢出的代码审计，审计内容主要包括：

1基于外部输入的数据控制程序自身的行为，如：

2代码基于的函数的输入，其长度不是确定的值。

3代码过于复杂以致无法预测它的行为。

7.电子渠道信息系统应对系统代码进行整数溢出的代码审计，审计内容主要包括：

1对有符号整数，无符号整数或是指针等类型的变量做运算时，返回的结果数过大或者过小超出了变量类型所能表示的最大或最小范围导致的整数溢出。

2处理用户输入为不定长度的结构体。

8.电子渠道信息系统应对系统代码进行跨站脚本的代码审计，审计内容主要包括：

1存储型XSS：如果对数据库中存储的所有数据没有一个适当的输入验证，那么测试人员就能够在用户的浏览器上执行测试内容。

2存储型XSS：通常是由测试人员将测试内容注入数据存储中，然后该内容被读出并包含在动态内容中。

3反射型XSS：通常是由测试人员向有漏洞的web应用程序提供测试内容，诱使用户访问这一有漏洞的站点应用程序，然后这些测试内容会反射给用户并由浏览器执行。

9.电子渠道信息系统应对系统代码进行SQL注入的代码审计。

10.电子渠道信息系统应对系统代码进行资源注入的代码审计，审计内容主要包括：

1攻击者能否指定用于访问系统资源的标识符（如：攻击者能够指定用来连接网络资源的端口号）。

2通过指定该标识符，攻击者能否获得他原本不具有的能力。

11.电子渠道信息系统应对系统代码进行资源泄露的代码审计，审计内容主要包括：

1查看是否存在程序出现错误和其他异常情况，或者程序负责释放资源的某个部分发生混乱的时候，程序因释放系统资源失败而导致的资源泄露。

12.电子渠道信息系统应对系统代码进行命令注入的代码审计，审计内容主要包括：

1攻击者是否可以改变应用程序执行的命令。

2攻击者是否可以改变命令执行的环境。

13.电子渠道信息系统应对系统代码进行拒绝服务的代码审计，审计内容主要包括：

1迫使服务器的缓冲区满，不接收新的请求。

2使用IP欺骗，迫使服务器把合法用户的连接复位，影响合法用户的连接。

14.电子渠道信息系统应对系统代码进行路径遍历的代码审计，审计内容主要包括：

1是否能够利用当程序允许用户通过输入来控制文件系统操作使用的路径通过非法或越界路径访问或修改被保护的系统资源。

6.3.3代码部署

1.电子渠道信息系统应确保将服务器系统，开发框架和组件版本升级至最新。

2.电子渠道信息系统应确保将服务器系统，开发框架和组件所有补丁更新至最新。

3.电子渠道信息系统应关闭目录列表。

4.电子渠道信息系统应Web服务器，进程和服务帐户仅分配到完成业务必须的最小权限。

5.电子渠道信息系统应去除所有不必要的功能和组件。

6.电子渠道信息系统应在系统上线前删除所有的测试代码以及无用代码。

7.电子渠道信息系统应防止robots.txt中泄露含有敏感信息的目录结构，应在robots.txt中设置拒绝搜索引擎收录含有敏感信息的页面或目录信息。

8.电子渠道信息系统应禁用不必要的HTTP方法（如：WebDAV扩展），如果扩展HTTP方法是必需的，应当采用认证机制。

9.电子渠道信息系统应将HTTP响应头中不必要的信息（操作系统类型及版本，Web服务器版本和应用程序框架）删除。

10.电子渠道信息系统应建立软件变更控制管理程序以明确掌握代码在开发和生产中的变化。

11.电子渠道信息系统应删除或更改所有默认数据库管理密码。使用强密码或实施多因素身份验证。

12.电子渠道信息系统应关闭所有不必要的数据库功能（如：不必要的存储进程或服务、工具包）只安装最低要求的功能和选项。

13.电子渠道信息系统应删除不必要的默认内容（如：示例模式）。

6.4数据安全

6.4.1数据保密性

1.应对保留在电子渠道信息系统上的BSS系统敏感信息（如：详单、个人信息）进行加密存储。

2.若电子渠道信息系统中存储有以下但不限于以下重要应用信息：用户登录口令、个人信息、交易记录、充值卡密，应对这些重要信息数据进行加密存贮。

3.应加密存储敏感系统信息（如管理员密码、配置文件等）。

4.不应将重要文件（如日志文件、代码备份文件、数据库文件等）存放在Web内容目录下，防止被攻击者直接下载。

5.当系统充值卡密从ftp服务器下载，并由相关人员进行了脱密后，若使用移动存储介质进行数据摆渡，移动存储介质入库前应存在加密机制对数据进行加密。

6.4.2数据完整性

1.电子渠道信息系统应能够检测到重要用户数据在传输过程中完整性受到破坏。

2.电子渠道信息系统应能够检测到鉴别信息和重要业务数据在传输过程中完整性受到破坏。

3.电子渠道信息系统所在主机应具备相应机制（如：采用“写前记录”方式的文件系统），保障当运行中的系统突然崩溃，磁盘数据处于不确定状态的情况下时，能够保证数据的完整性。

4.所有的数据校验过程应在可信任的系统上进行（如：服务器端或BSS系统）。

6.4.3数据可用性

1.电子渠道信息系统应能够对重要信息（如：业务日志、业务流水状态、业务历史记录）进行备份和恢复。

2.电子渠道信息系统应提供关键网络设备、通信线路和数据处理系统的硬件冗余，保证系统的可用性。

3.电子渠道信息系统所在主机磁盘卷管理应具备相应校验和容错机制（如:镜像和条带）来提供冗余。

4.电子渠道信息系统所在主机内存储器应具备相应校验和容错机制（如：ECC）来提供容错。

5.电子渠道信息系统应提供数据本地备份与恢复功能，完全数据备份至少每周一次，备份介质场外存放。

6.电子渠道信息系统应采用集群技术提供数据高可用性，以保障当单点失效时由集群管理系统分配备用的服务器接替工作。