信息系统安全技术规范

1、QB/CUXXX-200X 中国联通公司发布2011-10-01实施2011-10-01发布中国联通电子渠道安全技术规范China Unicom Electronic Channel Security Technical Specification（V1.0）QB/CU XXX-XXXX中国联通公司企业标准 目次前言II第一章范围1第二章规范引用性文件1第三章缩略语和术语定义1第四章电子渠道安全技术规范概述34.1电子渠道安全技术规范范围34.2电子渠道安全技术规范内容3第五章电子渠道信息系统整体安全技术架构3第六章电子渠道安全技术要求46.1业务安全46.1.1登陆办理类46.1.2信息查询

2、类56.1.3电子商城类66.1.4缴费充值类66.1.5页面展示类76.2应用安全76.2.1身份鉴别76.2.2访问控制86.2.3入侵防范96.2.4安全审计96.2.5剩余信息保护96.2.6通信完整性96.2.7通信保密性96.2.8抗抵赖106.2.9资源控制106.3代码安全106.3.1代码开发106.3.2代码测试186.3.3代码部署196.4数据安全206.4.1数据保密性206.4.2数据完整性206.4.3数据可用性20前言为了规范中国联通电子渠道系统的安全防护建设，中国联通制定了以下安全规范:（1） 中国联通电子渠道安全技术规范（2） 中国联通电子渠道安全测试规范本

3、标准是其中的中国联通电子渠道安全技术规范。本标准是在充分了解中国联通ECS、ESS系统的安全建设情况以及未来规划，参考相关行业标准的基础上，编制而成。本标准由中国联通公司电子渠道中心提出，并由中国联通公司技术部统一归口管理。本标准主要起草单位：中国联通公司电子渠道中心。本标准主要起草人：刘江林、金波、吴盛博、陈晓光、刘宇航等。本标准的修改和解释权属中国联通公司。21中国联通电子渠道安全技术规范第一章 范围本规范规定了电子渠道ECS、ESS系统的安全技术规范，适用于中国联通总部电子渠道中心，是中国联通ECS、ESS系统的应用安全技术规范和依据。本规范为总部电子渠道ECS、ESS系统提供安全技术规

4、范。第二章 规范引用性文件173-2010中国联通电子渠道技术规范v1.0YD/T 2092-2010 网上营业厅安全防护要求YD/T 1752-2008 支撑网安全防护要求YD/T 1728-2008 电信网和互联网安全防护管理指南YD/T 1729-2008 电信网和互联网安全等级保护实施指南YD/T 1730-2008 电信网和互联网安全风险评估实施指南YD/T 1731-2008 电信网和互联网灾难备份及恢复实施指南第三章 缩略语和术语定义本规范所涉及的缩略语定义如下：缩略语英文全称中文全称ECSElectronic Channel System电子渠道系统ESSElectronic

5、Sales Services Management System电子化销售服务管理系统BSSBusiness Support System业务支撑系统IPSIntrusion Prevention System入侵预防系统IDSIntrusion Detection System入侵检测系统SSLSecure Sockets Layer安全套接层ECCError Correcting Code错误检查和纠正本规范所涉及的术语定义如下：术语解释与说明电子渠道信息系统中国联通电子渠道信息系统直接面向互联网开放，通过Web、短信、WAP等多种渠道，提供话费积分查询、业务定制、充值交费、销售管理等创新

6、型业务应用，在本规范中则限指ECS、ESS两大系统。组织由不同作用的个体为实施共同的业务目标而建立的结构，组织的特性在于为完成目标而分工、合作。一个单位是一个组织，某个业务部门也可以是一个组织。业务电子渠道信息系统支持的业务过程，通常包括多步活动，并与用户、客服等多人间有交互，例如话费积分查询、业务定制、充值交费、销售管理业务等。开发框架开发框架即framework，是一组功能实现套件的结合体，提供了应用系统各个功能开发的最佳实践集合，使开发更具工程性、简便性和稳定性缓冲区溢出攻击缓冲区溢出攻击是指当计算机向缓冲区内填充数据时，数据位数超过了缓冲区本身的容量，溢出的数据覆盖了合法数据。如果程序

7、的返回地址被覆盖，当程序返回时，就有可能返回到攻击者的恶意代码段，而执行恶意代码。整数溢出攻击因为计算机表示数据的局限性，对有符号整数，无符号整数或是指针等类型的变量做运算时，返回的结果数过大或者过小超出了变量类型所能表示的最大或最小范围，就会导致整数溢出。如果程序不考虑整数溢出问题会导致逻辑错误或缓冲区溢出等风险。跨站脚本攻击入侵者在远程Web页面的HTML代码中插入具有恶意目的的数据，用户认为该页面是可信赖的，但是当浏览器下载该页面，嵌入其中的脚本将被解释执行，从而威胁用户浏览过程的安全。SQL注入攻击攻击者构造恶意的字符串，欺骗应用系统用于构造数据库查询语句并执行，从而达到盗取或修改数据

8、库中存储的数据的目的。资源注入攻击资源注入攻击是指在程序允许用户通过输入来控制资源标识符的情况下，攻击者能够访问或修改其他被保护的系统资源。资源泄漏攻击资源泄漏攻击是在程序出现错误和其他异常情况，或者程序负责释放资源的某个部分发生混乱的时候，程序因释放系统资源失败而导致的。命令注入攻击命令注入攻击是指在应用程序执行命令时没有指定一个完整的路径或者校验执行的代码，而使攻击者可以通过改变$PATH或其他环境变量，或者在搜索路径中插入可执行恶意代码，通过执行这些恶意代码应用程序会给予攻击者特殊的权限或者能力，而这些权限或能力是攻击者不应该具有的。拒绝服务攻击拒绝服务攻击是攻击者通过向应用程序发送大量

9、请求来使得应用程序无法向合法用户提供服务，即攻击者想办法让目标机器停止提供服务或正常用户的资源访问，这些资源包括磁盘空间、内存、进程甚至网络带宽。路径遍历攻击攻击者操纵输入参数使应用系统执行或透露任意文件内容，或对服务器任意文件目录进行读、写、删除等操作。命令注入攻击命令注入攻击是指攻击者操纵输入参数使应用系统执行额外的指令，例如操作系统命令等。第四章 电子渠道安全技术规范概述4.1 电子渠道安全技术规范范围中国联通电子渠道安全技术规范是围绕中国联通网上营业厅、电子化销售服务管理系统和企业门户三大业务应用，以业务安全、应用安全、代码安全和数据安全为重点，研究和编制符合中国联通电子渠道在线电子商

10、务特点的安全防护技术规范，制定电子渠道信息系统的业务和应用在设计、开发、部署、运行、维护等全生命周期各个环节应满足的安全技术要求。4.2 电子渠道安全技术规范内容电子渠道安全技术规范主要对子渠道信息系统的应用安全、业务安全、代码安全和数据安全技术防护要求进行阐述。第五章 电子渠道信息系统整体安全技术架构图 5-1 电子渠道系统安全技术整体技术架构第六章 电子渠道安全技术要求6.1 业务安全6.1.1 登陆办理类1. 电子渠道信息系统应对用户注册过程执行统一的口令策略，包括：1 口令设置者(如:系统颁发或用户自行设置)。2 如果系统必须颁发初始口令，应该避免使用统一的用户初始口令，应强制要求用户

11、在初次登录系统时修改初始口令。3 口令长度。4 口令至少包含的特征组(如：小写字母，数字，大写字母以及特殊符号等)。5 用户不应使用出现在常见列表中的口令类型(如:常见字符、词组、用户名作为密码等)。2. 电子渠道信息系统对于用户自助形式首次注册帐户的激活操作应使用其他方式（如：短信、邮件、手机号绑定、固话号码绑定等）进行确认。 3. 电子渠道信息系统应为注册功能模块设置强验证码机制，防止机器人恶意注册，验证码的抗识别强度要求包括：1 包含的特征组（如：大小写字母、数字组合，去掉歧义字符，0和o、l和1、z和2、q和9。）。2 应采用的算法（如：符号扭曲、粘连算法）。3 应采用的元素（如：字体

12、）的间距不规则分布。4 应加入的干扰元素（如：一条干扰斜线，覆盖所有字符）。5 背景色彩应使用的颜色（如：与网站整体风格一致）。6 后台验证码生成算法应定期更新(建议每3月更新一次)。7 验证码应设置超时时限（如：小于等于5分钟）。4. 电子渠道信息系统帐户注册过程应强制要求用户必填项信息（如：手机号、姓名、身份证号码等），并验证其必填项信息（如：手机号、身份证号码等）以及凭据找回渠道的有效性和真实性（如：邮箱、手机号必须真实且为帐户注册人持有）。5. 电子渠道信息系统应分系统不同制定多因素、多方式的登录认证功能，包括：1 ESS系统应具备多因素认证机制（如：口令+电子钥匙）。2 ECS系统应

13、具备多方式的认证机制（如：手机号/服务密码，手机短信随机密码，用户名/口令）。6. 电子渠道信息系统应为认证功能模块设置强验证码机制，防止恶意暴力破解，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。7. 电子渠道信息系统在用户成功登录后，应将上一次的登录信息（如：登录时间、地点、认证结果等）显示给用户。8. 电子渠道信息系统应禁用“自动登录”或“记住密码”等功能(如:网厅、手机厅)。9. 电子渠道信息系统认证失败的提示内容不应该指明具体错误的部分（如：登录信息错误时都提示“无效的用户名和/或密码”而不是“无效的用户名”或“密码无效”）。10. 应按用户登录电子渠道信息系统的不同方式，

14、实现用户操作功能权限的横向、纵向隔离，不但应保证用户登录后只能访问该用户的相关信息，不能非法访问其它用户相关信息，而且只能实现该方式下运营商开放给用户的系统功能。11. 电子渠道信息系统应对关键业务的办理执行严格的二次认证：1 对于需要手机号绑定的用户账户 (如ECS的网站用户绑定手机号码的操作)，应采用手机短信动态口令验证，并应设置动态口令超时时限为小于或等于1分钟。2 对于不与手机号绑定的用户账户 (如ECS的宽带、小灵通用户等不绑定手机号的账户类型)，应要求其提供可用邮箱地址，并通过邮箱激活邮件验证验证用户身份的真实有效性。12. 电子渠道信息系统应具备严格的防篡改机制，保证业务办理过程

15、中数据的完整性。13. 电子渠道信息系统业务办理类申请应具有二次确认机制，二次确认应采用多种方式进行（如：短信确认、再次点击确认等）。14. 电子渠道信息系统应具备完善的权限控制机制，保障用户在业务办理流程的每一步所具有的权限应受到功能级别细粒度的控制（如：2G用户不能办理3G用户业务）。15. 电子渠道信息系统每个业务办理流程应生成随机业务流水号，防止攻击者猜测标识或依据当前标识推导后续的标识。16. 电子渠道信息系统每个业务办理流程应生成时间戳，防止重放攻击。17. 电子渠道信息系统每个业务办理流程应具备自动退出机制，业务办理过程中，如果用户退出或会话意外中断、超时等情况，应重新进行认证。

16、18. 电子渠道信息系统应为账号的密码重置功能采用二次认证机制。二次认证要求按本规范6.1.1节第11)条执行。19. 电子渠道信息系统服务器端应保证同一业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。20. 电子渠道信息系统客户端页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到业务过程乱序的目的。21. 电子渠道信息系统应具备登陆办理类业务审计（日志）功能，并覆盖到每个用户，对重要业务信息（登录信息、认证结果、业务操作、数据信息、业务结果等）有详细记录。6.1.2 信息查询类1. 电子渠道信息系统应对详单查询操作采取二次认证机制，二次认证要求见“登录办理类

17、”之11)中所示。2. 应按用户登录电子渠道信息系统的不同方式，实现用户详单查询操作功能权限的横向、纵向隔离，权限隔离按本规范6.1.1节第10)条执行。3. 电子渠道信息系统应为查询类功能提供强验证码机制，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。4. 电子渠道信息系统应对涉及用户隐私的查询类功能(如：详单查询)采用基于手机短信动态口令验证的二次认证机制。该类查询功能成功后应进行短信通知。5. 电子渠道信息系统应对查询频率进行限制。6. 电子渠道信息系统应对信息查询类业务需要接纳用户输入的数据接口，添加针对输入数据的符合性进行验证。(如身份证输入框，应对输入的字符种类和长度做相

18、应合法性验证，过滤有害字符)。7. 电子渠道信息系统服务器端应保证同一详单查询业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。8. 电子渠道信息系统页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到实现业务过程乱序的目的。9. 电子渠道信息系统应具备信息查询类业务审计（日志）功能，并覆盖到每个用户，对重要详单查询行为（用户信息、查询操作、认证结果、查询字段等）有详细记录。10. 电子渠道信息系统信息查询类日志记录内容中不应包含应用系统非必须的敏感信息（如：身份证号码、信用卡信息、通话详单、短信详单等）。6.1.3 电子商城类1. 电子渠道信息系统应具备完善的权

19、限控制机制，保障用户在商城购物流程的每一步都应查询其当前认证状态，并严格检查其权限。2. 电子渠道信息系统商城业务流程中各个数据交互环节，如果存在会对后续流程环节内容有影响的操作，应存在防篡改机制，对必须从客户端获取的参数采用加密传输机制，并在服务器端对该类参数进行合法性验证，使得业务流程设计时设定为不应篡改的数据（如：表示商品种类、金额、积分额度、付款状态等参数）其完整性得到保证。3. 电子渠道信息系统应为电子商城类交易功能提供强验证码机制，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。4. 电子渠道信息系统每个商城交易流程应生成随机订单号，防止攻击者猜测标识或依据当前标识推导后续

20、的标识。5. 电子渠道信息系统应对单个订单交易额度以及单个用户交易频率进行控制（防止洗钱行为）。6. 电子渠道信息系统应对积分兑换行为进行二次认证，积分兑换成功后应进行短信通知。7. 电子渠道信息系统客户端应对电子商城类业务中需要接纳用户输入的数据接口，添加针对输入数据的合法性进行验证(如：身份证输入框，应对输入的字符种类和长度做相应合法性验证，过滤有害字符)。8. 电子渠道信息系统电子商城类模块应对第三方系统接口数据进行加密传输，以保障交易数据的机密性。9. 电子渠道信息系统电子商城类模块应对第三方系统接口数据附加数字摘要，以保障交易数据的完整性。10. 电子渠道信息系统电子商城类交易中，虚

21、拟商品（如：充值卡）交易应记录强类型用户身份关联信息（如：手机号、身份证、姓名等）。11. 电子渠道信息系统应对电子商城交易类业务中被具体交易过程锁定的被购买商品(如：手机号，上网卡等)设定超时时限，对于长时间未交易成功的订单对应的被购买商品进行自动释放。12. 电子渠道信息系统客户端页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到实现业务过程乱序的目的。13. 电子渠道信息系统服务器端应保证同一商城购物业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。14. 电子渠道信息系统应具备电子商城类业务审计（日志）功能，并覆盖到每个用户，对重要交易信息（用户信息、交

22、易操作、交易物品、金额、积分额度、付款状态、付款方式等）有详细记录。15. 审计记录内容中不应包含应用系统非必须的交易信息（如：充值卡卡密、信用卡信息）。16. 电子渠道信息系统应具备电子商城类交易账目对账机制，定期核对交易账目收支情况。6.1.4 缴费充值类1. 电子渠道信息系统应为缴费充值类交易功能提供强验证码机制，验证码的抗识别强度要求按本规范6.1.1节第3)条执行。2. 电子渠道信息系统缴费充值类业务流程中各个数据交互环节，如果存在会对后续流程环节内容有影响的操作，应存在防篡改机制，对必须从客户端获取的参数采用加密传输机制，并在服务器端对该类参数进行合法性验证，使得业务流程设计时设定

23、为不应篡改的数据（如：缴费金额、充值卡金额，折扣率等参数）其完整性得到保证。3. 电子渠道信息系统应对单个交易（如：购卡、充值、缴费等）额度以及单个用户交易频率进行控制（防止洗钱行为）。4. 电子渠道信息系统缴费充值类页面应隐藏标志业务办理流程步骤的变量及参数值，防止通过修改该变量达到实现业务过程乱序的目的。5. 电子渠道信息系统缴费充值类模块应对第三方系统接口数据进行加密传输，以保障交易数据的机密性。6. 电子渠道信息系统缴费充值类模块应对第三方系统接口数据附加数字摘要，以保障交易数据的完整性。7. 电子渠道信息系统缴费充值类交易中，虚拟商品（如：充值卡）交易应记录强类型用户身份关联信息（如

24、：手机号、身份证、姓名等）。8. 电子渠道信息系统应提供必要的校验措施（如：设置充值卡密状态标志），实现当卡密处于非激活状态时，即使外部人员成功猜测并构造了充值卡密也无法通过系统校验，从而无法成功的进行充值。9. 电子渠道信息系统应具备足够的审计措施，实现对内部人员使用内部系统接口伪造缴费请求（如：直接对目标手机卡进行充值）等行为的监控，并设定交易账目对账机制，定期核对交易账目收支情况。10. 电子渠道信息系统服务器端应保证同一缴费充值业务流程中各个数据交互环节中客户端前后操作的身份一致性及合法性。11. 电子渠道信息系统应对缴费充值类业务中被具体交易过程锁定的被购买商品(如：充值卡等)设定超

25、时时限，对于长时间未交易成功的订单对应的被购买商品进行自动释放。12. 电子渠道信息系统应具备缴费充值类业务审计（日志）功能，并覆盖到每个用户，对重要交易信息（用户信息、交易操作、交易物品、数量、折扣率、金额、积分额度、付款状态、卡密提取状态、付款方式等）有详细记录。13. 审计记录内容中不应包含应用系统非必须的交易信息（如：充值卡卡密、信用卡信息）。14. 电子渠道信息系统应具备缴费充值类交易账目对账机制，定期核对交易账目收支情况。6.1.5 页面展示类1. 电子渠道信息系统展示类业务应提供必要的保障机制，保证向用户展示信息（如：套餐资费、优惠活动）的正确性。2. 电子渠道信息系统展示类业务

26、应提供必要的保障机制，保证非业务数据不应被呈现。3. 电子渠道信息系统展示类业务应提供必要的保障机制，保证用户预留信息被正确展示。4. 电子渠道信息系统应限制每页最大显示查询结果条目数量。6.2 应用安全6.2.1 身份鉴别 身份标识和鉴别1. 应提供专用的登录控制模块对登录电子渠道信息系统的用户进行身份标识和鉴别。2. 应提供登录电子渠道信息系统用户身份标识的唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用。3. 除登录密码外还应支持图片验证码或其它预防暴力猜测帐号密码的措施。4. 电子渠道信息系统应采用随机数生成图片验证码，严禁以任何

27、形式配置可反复通过系统验证的万能验证码。5. 应在图片验证码图片背景中插入噪点、干扰（如：斜线干扰、字体大小随机、字体位置分布不均匀等）。6. 对于无需登录的业务（如：购卡）应采用一次性短信或邮件验证码机制。7. 会话标识必须足够随机，防止攻击者猜测标识或依据当前标识推导后续的标识。8. 用户登录后必须分配新的会话标识，不能继续使用用户未登录前所使用的标识。9. 认证失败提示中不应指明具体失败的原因或字段，比如，应使用“无效的用户名或密码”来代替“无效的用户名”或“密码错误”。 密码设置策略1. 电子渠道信息系统应具有密码复杂度判断和提示机制，能够判断及显示用户当前密码的安全性等

28、级，当用户密码存在风险时应能够提示用户进行修改。 登录限制1. 应设置连续登陆失败次数阈值，一定时间内登录失败次数超过阈值应自动锁定账号。2. 应启用登录失败处理功能，可采取结束会话和自动退出等措施。 远程访问1. 应对重要电子渠道信息系统重要模块（如：管理门户）的访问进行加密，如采用https协议替代http协议。 登录警示1. 电子渠道信息系统应设置鉴别警示信息，当发现并阻止用户试图越权访问信息的行为时，应进行提示并描述未授权访问可能导致的后果。6.2.2 访问控制 通信控制1. 应对从互联网进入电子渠道信息系统的流量进行过滤，实现对

29、应用层HTTP协议命令级的控制。2. 电子渠道信息系统应具备会话超时机制，用户通过互联网与电子渠道信息系统Web服务器建立的会话处于非活跃一定时间后，电子渠道信息系统Web服务器设备应自动终止会话。3. 如果电子渠道信息系统启用了SSL加密，其版本应不低于3.0。4. 电子渠道信息系统不应将SSL设置为可选的方案，不应在使用443端口（SSL通信端口）的同时也接受80端口（一般的HTTP服务端口）请求，不应允许用户选择安全级别。 帐户管理1. 应至少6个月进行一次对管理账户的回顾检查，确认每个管理帐号的使用人员。2. 应限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默

30、认口令。3. 应及时删除多余的、过期的帐户，避免共享帐户的存在。4. 应根据电子渠道信息系统管理账户的角色分配权限，实现管理账户的权限分离，仅授予管理账户所需的最小权限。 敏感标记1. 应对重要信息资源（如：充值卡密、个人信息等）设置敏感标记。2. 应依据安全策略严格控制用户对具有敏感标记的重要信息资源所进行的操作。6.2.3 入侵防范1. 直接面向互联网为用户提供服务的电子渠道信息系统设备（如Web服务器设备）仅开放为登录电子渠道信息系统用户提供服务所必须的服务端口（如HTTP、HTTPS 对应端口及向BSS系统开放的端口），并采用技术手段监控端口通信情况。2. 电子渠道信息系

31、统功能模块应遵循最小建设原则，仅建设必要的组件和功能模块。3. 应在电子渠道信息系统与互联网的网络边界处部署IDS或IPS设备，检测、防御以下攻击行为：端口扫描、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP碎片攻击和网络蠕虫攻击等。4. 应能够检测到对电子渠道信息系统中主机进行入侵的行为，能够记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间，并在发生严重入侵事件时进行告警。6.2.4 安全审计 审记建立1. 应对电子渠道信息系统重要安全事件（如：攻击行为、非法操作等）进行审计。 审记记录1. 应提供覆盖到电子渠道信息系统每个用户的安全审计功能。 2. 应对电

32、子渠道信息系统用户的登录过程进行审计。3. 应对电子渠道信息系统重要页面（购卡、充值、付款）操作进行审计。4. 审计记录的内容应至少包括事件日期、时间、发起者信息、类型、描述和结果等。5. 审计记录内容中不应包含应用系统非必须的用户身份信息（如：身份证号码）。6. 审计记录内容中不应包含应用系统非必须的交易信息（如：充值卡卡密、信用卡信息）。 审计管理1. 应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。2. 应保护审计进程，避免受到未预期的中断。3. 应保证无法删除、修改或覆盖审计记录。4. 应采用技术手段（如：定期运行文件完整性监控软件），能够发现应用系统关键数

33、据或文件被非授权更改并通知相关人员，应至少每周对关键文件进行比较。6.2.5 剩余信息保护1. 应采用技术手段保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除，无论这些信息是存放在硬盘上还是在内存中。2. 应采用技术手段保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除。6.2.6 通信完整性1. 应采用约定通信会话方式的方法保证通信过程中数据的完整性。6.2.7 通信保密性1. 在通信双方建立连接之前，电子渠道信息系统应利用密码技术进行会话初始化验证。2. 应对通信过程中的敏感信息字段（如：充值卡密、个人信息等）进行加密。6.2

34、.8 抗抵赖1. 电子渠道信息系统应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能。6.2.9 资源控制1. 电子渠道信息系统应提供访问控制功能控制用户组/用户对系统功能和用户数据的访问。2. 电子渠道信息系统应配置访问控制策略，并严格限制默认用户的访问权限。3. 访问控制的覆盖范围应包括与资源访问相关的用户、信息及它们之间的操作。4. 应能够对单个用户帐户的多重并发会话进行限制。5. 应能够对一个时间段内可能的并发会话连接数进行限制。6. 当用户无效登陆次数超过阈值（如：5次），应对账户进行锁定，且锁定时间应当足以阻止暴力的凭据猜测（如：30分钟）。7. 应能够对一个访问帐户或

35、一个请求进程占用的资源分配最大限额和最小限额。8. 应能够对系统服务水平降低到预先规定的最小值进行检测和报警。9. 应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话。6.3 代码安全6.3.1 代码开发 通用规则1. 电子渠道信息系统应确保开发环境与生产运行环境间具备隔离措施。2. 电子渠道信息系统应对来自客户端的重要数据（如：用户信息、交易操作、交易物品、数量、折扣率、金额、积分额度、付款状态、卡密提取状态、付款方式等）进行认证，包括那些不容易被客户修改的值（如cookies，隐藏域）。3. 电子渠道信息系统程序的逻辑处理与验证不应依赖访问请求到达的

36、顺序，防止攻击者随意控制访问请求到达的顺序来适合自己的需要，（如：程序通过不同页面来搜集信息，在较早的表单里验证了信息，而在修改信息的表单则没有进行验证，那么攻击者就可以利用后者来绕过输入验证）。 输入验证1. 电子渠道信息系统应对所有数据来源的可信度进行分类（如：可信/非可信），要求在程序中定义清晰的可信边界，代码中用于保存可信数据（如：服务器端数据）的数据结构，不能被用来存储不可信（如：客户端、网络端）数据。2. 电子渠道信息系统应对所有属于非可信类别数据源进行验证（如：用户输入、客户端文件流等），不能通过验证的数据将会被拒绝或丢弃，以确保在输入验证之前，输入的数据不能进入程

37、序代码中被执行。3. 电子渠道信息系统应维护一个可信的边界，不可信数据应单独存放在专门存放不可信数据的数据结构内，在经过验证之后才被放在可信区域。4. 电子渠道信息系统收到无法处理的或错误的输入应进行统一的失败控制，默认策略应对输入进行拒绝或丢弃。5. 电子渠道信息系统应拒绝所有验证失败的输入行为，不应试图修复一个未能通过输入验证的数据请求，应直接拒绝掉该请求。6. 电子渠道信息系统应对所有由客户端提交的数据在处理前进行检查，包括所有的参数、URL、HTTP头内容（如：Cookie，Get，Post，Referr）、JavaScript、Flash、或其他的嵌入代码。7. 电子渠道信息系统应对

38、来源于网络的数据进行校验，保证数据包的大小和内容都是与预期要求相符的，这些威胁体现在网络通信的一切行为中（如：从DNS返回的信息可能被假冒，数据包中非负荷数据也可能被伪造，攻击者可以专门构造数据包用于进行某些攻击等等）。8. 电子渠道信息系统应确保请求和响应头中的值仅包含ASCII字符。9. 电子渠道信息系统应避免通过用户控制的参数来重定向或包含另外一个网站的内容。10. 电子渠道信息系统应验证输入数据类型是否合规。11. 电子渠道信息系统应验证输入数组范围是否合规。12. 电子渠道信息系统应验证整数输入的边界值是否合规。13. 电子渠道信息系统应验证输入数据长度是否合规，验证时，应该检查输入

39、的最小和最大长度。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

40、 反斜线和点(./ 或 .以及 %c0%ae%c0%ae/)。 输出验证1. 电子渠道信息系统中对来源于外部的数据（包括用户输入、文件、网络、数据库等）输出时，应对输出信息进行转义，过滤其中的元字符，从而阻止输出的数据中夹带的恶意代码（例如XSS攻击）对终端用户的威胁。 认证及密码管理：1. 电子渠道信息系统应对所有网页和资源的访问进行身份认证，除了设定为对公众开放的资源（如：网厅首页）。2. 电子渠道信息系统的所有身份认证过程应在可信系统上进行（如：服务器端），防止攻击者绕过请求页面和浏览器，直接与应用服务器进行通信（如：不应使用JavaScript的验证逻辑，J

41、avaScript可以帮助合法的用户对不正常的输入信息进行检测，但是不能确保服务器接收到数据的安全性）。3. 电子渠道信息系统应拒绝所有认证失败的访问并提示错误。4. 电子渠道信息系统应采用足够强度添加随机值的单向哈希算法来保证密匙和凭据的存储（应尽量避免使用MD5算法），同时，应只能通过电子渠道信息系统能够对存储密码的表或文件进行写操作。5. 电子渠道信息系统的所有密匙和凭据哈希过程应当在可信系统上进行（如：服务器端）。6. 电子渠道信息系统的身份认证过程，应仅在完成所有的认证信息（如：密匙和凭据）输入后才开始。7. 电子渠道信息系统应采用统一的口令策略，包括：1 用户应自己设置口令。2 如

42、果系统必须颁发初始口令，应该避免使用统一的用户初始口令，应强制要求用户在初次登录系统时修改初始口令。3 口令必须包含至少6个字符。4 口令至少包含2个特征组：小写字母，数字，大写字母以及特殊符号（服务密码除外）。5 用户不应使用出现在常见列表中的口令。6 用户不应使用与其用户名类似的口令。8. 电子渠道信息系统认证失败的提示内容不应该指明具体错误的部分（如：登录信息错误时都提示“无效的用户名和/或密码”而不是“无效的用户名”或“密码无效”）。9. 应使用安全的方法存储口令，包括：1 不应明文存储口令。2 口令在存储前应通过安全的单向hash函数转化为不可还原的形式。3 不应在通信内容中包含口令

43、。4 不应在错误信息中包含口令。10. 电子渠道信息系统应对与涉及敏感信息（如:卡密、详单等）或功能的外部系统（如：BSS）连接进行二次认证（如：手机短信动态口令验证）。11. 电子渠道信息系统应使用安全的方法进行口令找回，包括：12. 应通过邮箱、短信形式发送临时验证码，通过临时验证码验证后，设置新密码。13. 电子渠道信息系统应只使用HTTP POST请求发送身份验证凭据。14. 电子渠道信息系统应采用加密连接或数据加密发送认证信息（如:密匙和凭据）。15. 电子渠道信息系统各个身份验证页面，应使用相同位数的同一特殊字符（如：*和#）代替以明文方式显示密码（如：服务密码）。16. 电子渠道

44、信息系统帐户注册过程应验证其凭据找回渠道的有效性和真实性（如：邮箱、手机号必须真实且为帐户注册人持有）。17. 电子渠道信息系统帐户密码的更改及重新设定，应具备二次认证机制。其安全控制措施不应少于帐户的注册及认证。18. 应使用其它方式确认并通知用户信息的修改，包括：1 应在用户改变其帐号信息时（如修改口令或者重置口令），对当前用户口令进行校验。2 应要求用户通过email等方式来确认其改变的行为。3 不应在确认邮件中包含认证信息。4 当用户改变其联系信息时，应将改变通知同时发送给旧的email地址和新的email地址。19. 电子渠道信息系统应执行口令重置策略，包括：1 口令重置应是一个自动

45、过程，在正常操作流程下，不应有人为的干涉。2 用户应在其第一次创建口令的时候建立一个安全问题以及对应的答案。3 如果用户的身份不能通过用户名、安全问题以及答案来确定，用户应提供其身份的证明。20. 电子渠道信息系统帐户密码的更改及重新设定操作如果使用基于短信或电子邮件的复位，应只发送含有一个临时的验证码的短信或电子邮件至预先登记的邮件地址。21. 电子渠道信息系统帐户的临时验证码，应设置一个短的过期时限（如：5分钟）。22. 当用户帐户发生密码重置或修改行为，应及时通知用户（如：短信或邮件）。23. 电子渠道信息系统应禁用“自动登录”或“记住密码”等功能。24. 电子渠道信息系统应将用户预留信

46、息（防钓鱼），在用户登录成功后进行提示。25. 电子渠道信息系统应将用户最后一次登陆帐户的结果（如：成功或不成功），在用户下一次登录成功后进行提示。26. 电子渠道信息系统应对开发过程中内置默认帐户或密码的通信采用加密机制。 会话管理:1. 电子渠道信息系统应使用会话管理控制程序，系统应只响应被控制程序标识为有效的会话。2. 创建会话标识符的过程应始终在可信任的系统上进行（如：服务器端）3. 会话标识必须足够随机，防止攻击者猜测标识或依据当前标识推导后续的标识，应使用一种生成代价小并满足安全需求的随机数生成方法来生成应用程序需要的随机数，目前有如下三类生成方案：1 不安全的随机数

47、生成器，这是一种非密码学的伪随机数生成器，攻击者可以知道生成器能够输出的数值。2 密码学的伪随机数生成器，这是一种使用一个单一的安全种子来产生许多不可猜测的随机数的方法，该方案在多数情况下是安全的，最重要的是其使用的安全种子。3 信息熵收集器，该方案在一些时候是“真正的”随机数生成器，其主要工作是收集来自其它源以及自身的信息熵。但是其产生数据的速度过慢。根据以上方案具体要求如下：1 不应使用不安全的随机数生成器。2 应使用信息熵作为密码学伪随机数生成器的种子，但在生成长期的密钥的情况下，不使用这种方法。3 若需要相同的数据流，就不能修改生成器的种子，因为在使用固定的种子时密码学伪随机数生成的输

48、出流也是固定的。4 使用能够获取好的随机数的方案。不应使用熵很低或容易被猜到的种子，例如时间、日期或空种子。5 在Java中，使用SecureRandom类，不要使用Random类，SecureRandom类的默认构造方法可以正确选种，Java会自动获取一个信息熵比较平均的值。6 最好使用硬件的随机数生成器，要求其在没有收集到足够的真实随机序列来生成种子时，就会中断。如果使用的是不会中断的，要求在使用之前仔细测试是否有足够的种子。7 使用操作系统或者其使用的加密库的一个真实的随机源8 在Unix平台上，从/dev/urandom读取16字节可以给出相当高质量的随机序列。9 在Linux中，/d

49、ev/urandom是不中断的，并且总会返回请求的字节数，但/dev/random在没有足够的真实随机序列时则会中断。4. 用户登录后必须分配新的会话标识，不能继续使用用户未登录前所使用的标识。5. 用户退出登陆后应完全终止相关的会话或连接。6. 所有被身份认证机制保护页面都应提供账户退出功能。7. 电子渠道信息系统会话ID长度不应低于64位，建议使用128位长度的会话ID8. 在确定会话ID的长度以及生成ID的随机种子之前，不应相信web程序的容器，因为会话ID太短很容易被暴力猜解，如果攻击者能猜到授权用户的会话ID就可以接管用户的会话。9. 电子渠道信息系统应禁止相同的用户ID同时登录。1

50、0. 不应在url中显示会话标识符、错误信息或日志，会话标识符应只包含于HTTP cookie头中（如:不应通过GET参数传递会话标识符）。11. 电子渠道信息系统应采用实施适当的访问控制措施，防止服务器上的其他用户未经授权访问服务器端的会话数据。12. 电子渠道信息系统应规定一个会话最大空闲时间，具体要求如下：1 应强制执行一个会话最大空闲时间，建议将超时时间设置为小于30分钟以缩短那些未能及时注销的用户暴露在外的时间，减少可供攻击者猜解的会话ID平均数目。2 应将应用程序框架将会话最大空闲时间设置为可配置的参数，并提示相关人员如何进行正确的设置。13. 电子渠道信息系统应允许用户主动注销或

51、结束当前会话。 访问控制1. 电子渠道信息系统应限制只有授权的用户能访问受保护的URL（如：系统管理界面）。2. 电子渠道信息系统应限制只有授权的用户能访问受保护的功能（如：系统管理功能）。3. 电子渠道信息系统应限制只有授权的用户能引用受保护的对象（如：系统内部接口）。4. 电子渠道信息系统应限制只有授权的用户能引用受保护的接入服务。5. 电子渠道信息系统应限制只有授权的用户能引用受保护的应用数据。6. 电子渠道信息系统应限制对用于访问控制的相关数据和策略的访问和操作。7. 电子渠道信息系统应限制只有授权的用户能访问安全相关的配置信息。8. referer头应只作为辅助检查手段

52、，不应作为唯一授权检查手段。9. 电子渠道信息系统应定期重新验证用户的授权，以确保其权限没有改变，对于所有的权限变更行为，应注销登陆，并迫使用户重新进行认证。10. 电子渠道信息系统应支持当授权终止时自动锁定帐户及终止当前会话（如：角色变更、权限变更、策略变更、业务流程变更等）。11. 电子渠道信息系统应对文件系统进行访问控制，具体要求如下：1 文件只能被指定的用户访问，并且该用户的权限被限制为最小权限。2 当应用程序使用被其控制的已存在文件时，必须首先验证是否存在防止文件被篡改的许可权限，并且不能将许可权限的管理交给系统管理员一个人处理。3 为了安全的使用临时文件，要求在程序初始化时创建一个

53、只能被该程序读写的文件夹，不能将该文件夹放在用户可访问到的地方，并将所有的临时文件都放在其中，这样就可以防止攻击者猜测被使用的临时文件的名字，提前创建该文件来进行内容操纵或者拒绝服务攻击。12. 电子渠道信息系统应建立文件访问竞争条件，具体要求如下：1 确保在程序对某文件进行一系列操作之后，不应能被替换或者修改，在C语言中，避免使用操作文件名的函数，应该首先打开该文件获得文件句柄，然后通过使用操作文件句柄的函数来进行操作，因为不能够保证在函数调用域之外的空间上，它指向的仍是硬盘上同一文件。2 当用户可以访问本地文件时，不应使用Java来实现具有特定权限的程序，因为在Java中，虚拟机对文件的操

54、作是基于路径的，而不是操作系统的文件句柄的，所以文件访问竞争条件是不可避免的。13. 电子渠道信息系统应使用验证码以防止恶意登陆、破解尝试行为，验证码的抗识别强度应按照如下要求：1 为方便用户肉眼辨认，应采用大小写字母、数字组合，去掉歧义字符，0和o、l和1、z和2、q和9。2 应采用符号扭曲、粘连算法。3 应采用字体间距不规则分布。4 应加入一条干扰斜线，覆盖所有字符。5 背景色彩应使用与网站整体风格一致的颜色。6 后台验证码生成算法应定期更新(建议每3月更新一次)。7 验证码超时时限应小于等于5分钟。 数据加密1. 电子渠道信息系统中所有涉及敏感信息（如：卡密、详单、个人信息

55、）的加密过程应始终在可信任的系统上进行（如：服务器端）。2. 电子渠道信息系统应建立和执行加密凭据管理流程。3. 电子渠道信息系统应减小无用隐私信息的存活时间，保存隐私信息的时间应尽量的短（如：在认证后，不允许保留用户口令，包括在内存里），要求高安全级别的系统锁定内存分页，防止操作系统将这些数据缓存到磁盘的交换文件中。4. 电子渠道信息系统应尽量少的共享私密信息，不允许在客户端长期保存秘密信息，在选择了数据发送到客户端的时候，要假设任何通过客户端共享的数据都是不安全的。 错误处理1. 电子渠道信息系统不应在错误响应中携带敏感信息，包括系统的详细信息、会话标识符及帐户信息。2. 电

56、子渠道信息系统应使用不显示调试或堆栈跟踪信息的错误处理程序。3. 电子渠道信息系统应采用通用的错误提示信息，并为HTTP错误建立一个默认的错误页面，丢弃掉所有的异常，防止攻击者从应用程序的默认出错页面中得到系统信息。4. 电子渠道信息系统应构造错误提示信息来防止诸如用户id、网络、应用程序以及服务器环境的细节等重要的敏感信息的泄漏。包括：1 不应采用Web容器自身的错误信息页面。2 在返回的错误信息中不应包含主机信息、网络信息、DNS信息、软件版本信息、错误代码或者其它发生的错误的详细信息。3 不应把错误的细节放在错误页面的注释里。5. 电子渠道信息系统自身应具备处理应用程序错误的能力，不应依赖于服务器的配置处理异常和错误。6. 电子渠道信息系统应当错误情况发生时正确释放已分配的内存空间。7. 错误处理流程应与访问控制策略结合，错误处理默认策略应当拒绝默认访问。 日志记录1. 错误处理日志记录过程应始终在在可信任的系统上进行（如：