江苏东海农村商业银行客户端安全管理规范

前  言

本标准按照 GB/T1.1—2009给出的规则起草。

本标准由江苏东海农村商业银行股份有限公司提出。

本标准起草单位：江苏东海农村商业银行股份有限公司。

本标准主要起草人：李志、程陶、李政、海宇杰

江苏东海农村商业银行股份有限公司客户端安全管理规范

1　范围

本标准规定了移动金融客户端应用软件的安全要求，以及客户端应用软件设计、开发、维护和发布的管理要求。

本标准适用于移动金融客户端应用软件的设计、开发、维护及发布过程，也适用于评估机构对相关应用进行安全性和标准符合性评估。

2　规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T 35273-2017 信息安全技术个人信息安全规范

JR/T 0071-2012 金融行业信息系统信息安全等级保护实施指引

JR/T 0092—2019 移动金融客户端应用软件安全管理规范

3　术语与定义

下列术语和定义适用于企业标准编号的本标准（本部分）。

3.1　移动金融客户端应用软件  financial mobile application software 

在移动终端上为用户提供金融交易服务的应用软件。注：包括但不限于可执行文件、组件等。

3.2　金交易类客户端应用软件  capital transaction client application software 

直接面向用户提供资金交易服务的移动金融客户端应用软件。注：包括但不限于手机银行、支付APP等。

3.3　信息采集类客户端应用软件  information collection client application software 

不直接向用户提供资金交易服务，但需采集个人敏感信息的移动金融客户端应用软件。

3.4　资讯查询类客户端应用软件  information query client application software 

仅提供金融产品推介、信息查询、资讯推送等服务的移动金融客户端应用软件。

3.5　个人金融信息  personal financial information 

金融业机构通过提供金融产品和服务或者其他渠道获取、加工和保存的个人信息。注1：包括账户信息、鉴别信息、金融交易信息、个人身份信息、财产信息、借贷信息及其他反映特定个人某些情况的信息。

3.6　支付敏感信息  payment sensitive information 

支付信息中涉及支付主体隐私和身份识别的重要信息。注：包括但不限于银行卡磁道或芯片信息、卡片验证码、卡片有效期、银行卡密码、网络支付交易密码等。

3.7　语音识别  automatic speech recognition 

将人类语音中的词汇内容转换为计算机可读的输入。示例：按键、二进制编码或者字符序列。

3.8　语音合成  text to speech 

将文本信息转化为语音数据的技术，涉及声学、语言学、数字信号处理、多媒体等多种前沿的高新 科技。

3.9　自然语言理解  natural language processing 

使用自然语言同计算机进行通讯的技术。

3.10　第三方信源  the third party source 

客户端应用软件调用语音能力时可以接入的第三方服务。

4　缩略语 

下列缩略语适用于本文件。

APP：客户端应用软件（Application software）

URI：统一资源标识符（Uniform Resource Identifier）

TEE：可信执行环境（Trusted Execution Environment）

SDK：软件开发工具包（Software Development Kit）

SE：安全单元（Secure Element）

5　客户端应用软件安全要求 

5.1　身份认证安全

5.1.1　认证方式 

基本要求：

a)客户端应用软件登录时采用登录密码/手势密码/指纹验证，首次在设备上登录还需验证短信验证码、生物识别进行设备绑定。

b）身份验证要素相互独立，登录使用登录密码，交易时使用银行卡密码，短信验证码、动态口令具有时效性和一次有效性。

c）客户端应用软件交易时按照相关业务管理要求对用户身份进行认证，如：大额转账时需要验证短信验证码、证书、动态口令、交易密码等。

d)对于手势密码、短信验证码、生物特征信息作为验证要素或验证要素组合中的一种时，满足如下要求：若采用手势密码作为验证要素，手势密码应至少设置连续不间断的4个点；若采用短信验证码作为验证要素，短信验证码仅可使用一次，仅限于在3分钟内使用，短信验证码应长度6位，内容随机，短信验证码所在的短信内容中，告知用户短信验证码的用途，如：转账交易告诉向**尾号**转账**元；若采用生物特征识别作为验证要素，符合国家、金融行业标准和相关信息安全管理要求，如：人脸识别时需要采集动态动作，动作随机。

e）图形验证码使用时间3分钟并仅能使用一次，图形验证码由服务器生成，客户端源文件中不应包含图形验证码文本内容。

f）图形验证码不作为独立的身份验证要素，会校验其他验证要素，如：密码，短信等。

5.1.2　认证信息安全 

1.1.1.1　安全输入

基本要求：

手机银行架构提供安全键盘API，输入数据逐字符加密，传输过程中全程加密。提供的安全键盘类型有：数字键盘、金额键盘（比数字键盘多小数点）、身份证键盘（将数字键盘的小数点替换成字母X）。

1.1.1.2　个人金融信息展示

基本要求：

a)客户端应用软件的口令框默认屏蔽显示，屏蔽显示时使用同一特殊字符（•）代替，如：密码框。

b)客户端应用软件显示银行卡密码和网络支付交易密码都是••••••，密码经过加密处理。

c)客户端应用软件展示个人金融信息时，符合以下要求：

处于未登录状态时，不展示与个人信息主体相关的用户鉴别信息（如：卡片验证码、卡片有效期、登录密码、支付密码等）；·处于已登录状态时，个人金融信息展示的技术符合如下要求：¨不展示银行卡有效期，用户鉴别信息（如：登录密码、支付密码等）掩码展示；¨对于银行卡号、手机号码、证件号等前后展示内容中间信息脱敏展示，若需查看完整卡号，需校验短信验证码查看；¨涉及其他信息主体的信息时，未脱敏处理：n如：其他方主动发起收付款。

5.1.3　认证失败处理 

a)客户端应用软件提供认证失败处理功能，如：限制失败登录次数和锁定等措施。登录密码失败5次后锁定，交易密码失败3次后锁定。

b)在提示客户认证失败时，提示模糊错误信息，如：登录时密码错误提示用户名或密码错误等。

5.1.4　密码的设定与重置 

基本要求：

a)客户端应用软件设置密码时，服务端校验密码复杂度，保证用户设置的密码达到一定的强度，避免采用简单交易密码或与客户个人信息相似度过高的交易密码。

b)登录手机银行时，若设置的登录密码比较简单，则强制用户修改密码，并要求符合密码强度。

c)在修改密码前，需验证原密码和短信验证码。

d)修改密码时对原密码输入错误次数进行限制，登录密码5次，交易密码3次。

e)修改密码时新密码不能与原密码相同。

f)在密码重置时，需验证短信验证码、银行卡号的交易密码，人脸识别。

增强要求：

a)在进行修改密码或密码重置时，采用两种或两种以上要素进行身份认证，如：短信验证码、人脸识别等。

b)修改或重置密码时提示客户避免设置与常用软件、网站相同或相似的用户名和密码组合，并采取有效措施引导客户设置独立的支付密码，如：请避免设置与常用软件相同或相似的用户名和密码组合。

5.2　逻辑安全 

5.2.1　逻辑安全设计 

基本要求：

a)对于认证、校验等安全保证功能的流程设计应充分考虑其合理性，避免逻辑漏洞的出现，确

保认证流程无法被绕过。

b)对于交易处理功能逻辑设计应充分考虑其合理性，避免逻辑漏洞的出现，保证资金交易安全。

c)客户端代码实现应尽量避免调用存在安全漏洞的函数，避免敏感数据硬编码。

5.2.2　软件权限控制 

基本要求：客户端应用软件向移动终端操作系统申请权限时，应遵循最小权限原则。

客户端向移动终端操作系统申请权限时，已遵循最小权限原则。且敏感权限需用户同意，如：摄像头权限、定位权限。

5.2.3　风险控制  

基本要求：

a)当用户闲置在线状态超出时限时，会提示用户登录超时需重新登录，如：有效时间5分钟；多点登录策略，如：用户在其他手机设备或切换网络等，提示用户重新登录，用户信息变更后，也会提示重新登录

b)针对不同的资金交易金额，交易验证要素不同，如：小额转账时只需验证交易密码、短信验证码，大额的时候需要验证证书、短信验证码、交易密码、动态口令等；针对不同的资金交易业务场景，有相应的限额控制策略，如：转账限额、二维码限额，转账限额分为短信限额和动态口令限额，二维码限额分为免密限额，小额支付等

c)客户端应用软件应配合业务交易风险控制策略，以安全的方式将相关信息上送至风险控制系统，如：登录ip，设备号等信息加密上送到服务端。

5.2.4　回退处理 

5.2.5　异常处理  

基本要求：

a)客户端应用软件发生故障产生的异常信息，没有泄露用户的敏感数据。只打印异常信息

b)当交易出现异常时，客户端应用软件应向客户提示出错等信息，不包含客户敏感数据。

5.3　安全功能设计

5.3.1　组件安全 

基本要求：

a)客户端应用软件应避免使用存在已知漏洞的系统组件与第三方组件。

b)客户端应用软件在使用第三方组件时，应避免第三方组件未经授权收集客户端应用软件信息和个人信息。

5.3.2　接口安全 

基本要求：

严格控制组件export属性，防止部分组件被恶意使用引发程序异常。对客户端提供的可导出组件添加自定义属性，在需要调起组件的应用中需要申明使用该组件。

5.3.3　抗攻击能力 

基本要求：

a)客户端应用软件已做防动态调试处理。

b)客户端代码已使用代码加壳、代码混淆等手段对客户端应用软件进行安全保护。

d)客户端应用软件使用安全键盘输入控件，键盘输入采用一字一密，且防止截图等安全措施。

5.3.4　客户端应用软件环境检测  

客户端应用软件在运行时对运行环境检查了手机系统是否root。

5.4　密码算法及密钥管理 

5.4.1　密码算法  

基本要求：

a)客户端应用软件应使用密码算法对资金有关交易或重要业务操作进行保护。

b)密码算法、密钥长度及密钥管理方式应符合国家密码主管部门的要求。

5.4.2　密钥管理 

a) 随机生成的密钥为16位随机字符。

b) 密钥在传输过程中应使用密码算法对密钥进行保护；

c) 随机生成的密钥应具有一定的随机性与不可预测性；

d) 密钥应加密存储，并确保密钥储存位置和形式的安全。

5.5　数据安全 

5.5.1　数据获取 

5.5.1.1　数据防窃取

a) 客户端应用软件不保存银行卡密码及网络支付交易密码。

• 客户端应用软件的临时文件中不应出现支付敏感信息，临时文件包括但不限于Cookies、本地临时文件等。
• 客户端在输入手势密码，使用安全键盘输入登录口令等时，禁止截屏。
• 客户端应用软件程序应禁止在身份认证结束后存储支付敏感信息，防止支付敏感信息泄露。
• 客户端应用软件运行日志中不应打印支付敏感信息、不应打印完整的敏感数据原文。
• 应采取技术手段防止内存中加密的敏感数据被还原为明文。

5.5.1.2　数据防篡改

用户输入关键交易数据，客户端采用安全密码键盘，且数据传输过程采用加密及验证md5等手段保证数据不被其他程序篡改。

5.5.1.3　数据有效性

基本要求：客户端应用软件在数据获取时提供有效性校验功能，确保通过人机接口或通信接口输入的数据格式或长度等信息符合系统设定要求。

5.5.2　数据访问控制  

基本要求：

a)客户端采取登录、绑定、人脸识别、自定义权限方式，保证数据仅能被授权用户或授权应用组件访问。

b)客户端应用软件在授权范围内，只访问业务必需的文件和数据。

5.5.3　数据传输 

5.5.3.1　通讯安全  

基本要求：

a)客户端应用软件通过HTTP通信协议方式与服务端交互，使用HTTPS加密传输数据,X509证书必须满足条件：由根证书是操作系统安装的CA颁发。

b)TLS版本必须为TLS1.2，不使用老版本TLS的连接。

c)连接必须使用AES-128或AES-256对称加密算法，TLS协商算法必须通过ECDHE密钥交换保证完全正向保密（PerfectForwardSecrecy,PFS），ECDHE密钥必须属于下面一种：

服务器叶证书必须使用下列的密钥签名

5.5.3.2　数据保密性  

基本要求：

敏感数据(客户登陆信息等)不允许客户端应用软件与本地其他应用软件间明文传输，客户端应用软件仅提供一次性请求查询TOKEN方式与本地应用软件通过后台查询敏感数据。

5.5.3.3　数据完整性

基本要求：

a)关键的交易数据，如：收款人信息、交易金额、订单号等，在客户端应用软件与本地其他应用软件间传输时，应采取措施（如：数字签名、MAC等）确保其完整性，若本地其他应用软件不能提供与金融客户端软件相应等级的数据完整性保护措施，则应评估关键数据传输的风险，并设计补救措施。

b)关键的交易数据、个人身份信息，如：收款人信息、交易金额、订单号、身份证号码等，在通过公共网络传输时，应采取措施（如：数字签名、MAC等）确保其完整性。

5.5.3.4　数据抗抵赖

基本要求：通过客户端应用软件发起的资金类交易报文，应确保交易报文的不可抵赖性，在有条件的情况下应采用数字证书技术。

5.5.3.5　数据防重放

基本要求：通过客户端应用软件发起的身份认证或资金类交易报文，应能够防止重放攻击。

通过客户端发起的资金类交易，使用token方式防止交易报文重放。服务端生成一次性token，由服务端提供防重放检查。包含客户端及服务端两部分。客户端提供专用的防重复提交请求的API，供开发人员调用。防重复提交，客户端需向服务器申请一个访问令牌T（一次性会话值），在主交易请求时上传该T；服务端进行T会话检查，使用后立即消毁T值会话，达到一次使用目的。

5.5.4　数据存储  

5.5.4.1　个人金融信息存储  

基本要求：

a) 客户端应用软件不应以任何形式存储用户的支付敏感信息与金融业务查询口令。

b) 客户端应用软件应向个人金融信息主体告知共享、转让个人金融信息的目的、个人金融信息接收方的类型，并事先征得个人金融信息主体明示同意。

c) 在满足法律、管理规定的前提下，客户端应用软件应仅保存业务必需的个人金融信息，并限制数据存储量。

d) 在个人金融信息加工处理的过程中，应建立个人金融信息防泄露控制规范和机制，防止个人金融信息处理过程中的调试信息、日志记录等因不受控制的输出而泄露受保护的信息。

5.5.4.2　加密密钥存储

客户端应用软件应确保无法通过逆向工程等手段直接从本地文件系统中恢复完整的密钥明文。

5.5.4.3　数据展示  

客户端除交易对账、转账收款方确认等必须由用户确认的情况外对客户关键信息：银行账号、身份证号码、手机号码、付款码（数字）需要做脱敏展示。

5.5.5　数据销毁 

5.5.5.1　残余信息保护

基本要求：

a)客户端应用软件在敏感数据（如：输入登录密码）使用完毕后，会立即进行清除

b)客户端应用软件进程被结束时，会清除session保存的信息。保证客户信息的安全性。

c)客户端应用软件卸载完成后，文件系统中不应残留任何个人金融信息。

5.5.5.2　页面返回保护

基本要求：客户端应用软件应支持页面返回后自动清除银行卡密码、网络支付交易密码、登录口令等支付敏感信息的机制。

增强要求：

a)客户端应用软件具备页面返回后自动清除银行卡密码、网络支付交易密码、登录口令等支付敏感信息的机制。

b)当客户端应用软件从前台进入后台时，超过设定时限后会话信息会被清除销毁，客户需重新登录APP。

5.5.5.3　会话失效

客户端在安全退出时，会向服务器发送请求，销毁当前会话

5.5.5.4　平台安全报告

平台是国内第一个通过测试的与中国自主知识产权可信计算系统密切配合的应用开发平台。通过平台与可信计算系统的无缝整合，可实现网银系统、移动银行系統等应用程序的可信验证，符合国家信息系统安全等级保护的基本技术要求，使系统达到三级（含）以上的标准。

5.5.5.5　平台安全标准

平台在设计时严格遵照国家及国际安全标准确保系统的高度安全性，所采用的安全标准包括：

ISO9797（信息安全）

ISO13888（不可否认）

ISO7498（安全结构）

ISO9594（认证框架）

ISO17799（信息安全管理操作规范）

国产密码算法技术安全规范（SM1、SM2、SM3、SM4等）

5.5.5.6　平台安全组件

在应用安全方面，平台集成了大量应用安全模块，以保障系统的安全。下图为平台提供的部分安全组件，这些组件都可通过安全策略配置来实现客户化：

5.5.5.7　平台安全防御

在应用安全方面，平台集成了大量应用安全模块，以保障系统的安全。平台提供了丰富的安全组件，这些组件都可通过安全策略配置来实现客户化：

5.5.5.8　暴力攻击防范

平台提供灵活定义的密码防范策略供银行选择。例如密码连续错误超过3次数，冻结用户操作10分钟，密码连续错误超过5次数，冻结用户操作30分钟，第6次仍然错误，用户被永久冻结，用户必须亲自到银行柜台重置密码才可重新进行交易。以上仅为举例，以上数字，条件结果组合均可通过XML自由定义。平台的组件式设计，使得密码攻击防范组件不单可定义在系统登录交易，而且可以在所有用到密码的地方加入密码攻击防范控制，如转账-交易密码。

5.5.5.9　木马程序防范

平台提供客户端安全输入控件。通过建立专有的键盘处理机制，从物理层直接获取键盘的输入，再直接将密码交给应用程序，避免了Windows系统对键盘处理的漏洞，从而从根本上杜绝木马对用户账号和密码的盗取。针对现在已知的不同种类的木马，都完全可以防范此。控件在客户第一次访问系统时自动安装，无须人工干预。

5.5.5.10　网络嗅探防范

提供内置客户端数字证书加密功能，配合平台集成HSM组件，可提供端到端加密传输，从客户端到主机系统的全过程加密，密码不会中间过程任何环节以明文方式出现。可有效防止网络嗅探工具作案的可能，特别是内部网络的嗅探。

5.5.5.10.1　X.509 CRL Verification/UserId-DN Binding（证书检查/绑定）

e平台提供标准的证书废止列表检查方式，包括远程/本地LDAP访问，远程/本地CRL文件访问及下载等，保证与CA的废止列表服务器信息同步。除此之外，还会根据数据库中用户绑定的证书资料进行对比，确保是用户所属的合法证书。

5.5.5.10.2　 Role-Based Access Control（用户权限控制）

在用户登入时，平台会从数据库中或者主机返回数据装载用户权限或者账户权限，根据权限设定，控制显示或不显示功能菜单，用户在交易时，平台每次在内存中检查用户权限是否合法，有效地防止用户通过非正常途径，绕过界面操作非法进行交易。

5.5.5.10.3　 Style-Based Validation（单一域有效性检查及转码）

对用户提交的请求数据，平台提供两种方式做单一域有效性检查。

• 客户端检查。主要通过JavaScript实现。平台提供丰富的Javascript函数（以标准的js文件形式提供），程序员无须在页面写任何Javascript函数的函数，只需在页面模板中引用js文件，在Form表单元素设定check_style属性即可。
• 服务器端检查。主要通过XML实现，平台根据预设置的元素style类型，对数据进行判断。style类型可以定义正则表达式，可对数据做非常复杂的判断。
• 敏感字段转码、转换、特殊规则的检查等。

5.5.5.10.4　 Rule-Based Validation（交叉检查）

对于某些复杂的关联性检查，如金额大于10万元时必须有数字签名，平台对此类判断提供交叉检查功能。主要是在XML中，填写相应rule策略。平台会根据style、rule做交叉检查。平台支持将多个rule形成一个组，以满足更复杂的检查需求。

5.5.5.10.5　 Digital Signature Validation（数字签名验证）

平台提供标准的数字签名验证组件，满足X509证书的数字签名的合法性验证。除对签名的合法性验证外，平台还会将form表单提交的数据，与数字签名验证结果逐一进行对比，如对比结果有任何一项不符合，或者某一关键数据未做数字签名，平台仍会任何数字签名不合法。

5.5.5.10.6　 Event-Based Monitor & Managment（监控和管理）

监控系统完全基于平台开发。有别于同类产品采用的“PULL”模式，完全采用“PUSH”的方式来实现银行系统运行系统的实时监控。这种模式不会影响被监控系统的性能，而且可以保证集群环境下，所有被监控系统的统一监控。

提供攻击实时监控、交易实时监控、交易访问量实时监控、大额交易实时监控及统计、系统监控等。提供二次开发接口，可进一步扩展监控功能。

5.5.5.10.7　 Token Controller（动态口令）

平台提供动态口令产生动态口令、动态口令生命周期管理、动态口令检查等功能组件，可实现短信、手机软件等形式动态口令加强系统安全性。另外平台还开放扩展接口，支持对第三方动态口令的集成需求，如刮刮卡、动态令牌等。

5.5.5.10.8　 Re-submission Controller（防范重复提交）

用户的重复提交误操作会导致系统接受重复交易，主机系统多次扣账等严重后果。为此，平台对重复提交做了双重防范。

• 客户端防范。通过Javascript防范重复交易。用户点击按钮后，将按钮变灰不让用户多次点击。通过Javascript的alert提示语句，如用户多次点击提交按钮，给出友好提示，并组织提交服务器。
• 服务器端防范。在进行交易前，平台产生一次性口令，并隐藏在页面中，用户提交表单时，一次性口令随着表单数据一并提交，平台接受到请求后，判断一次性口令是否合法，如之前已经使用过，则表示属重复提交，给出友好的错误页面提示。

5.5.5.11　交易安全提醒控制

对于动账类的交易以及某些重要的管理类交易，平台提供了多种方式的通知组件，如短信、邮件等，告知客户本次交易的详细信息，以便客户在自己的电子银行系统被非法操作时能够第一时间得到通知。

5.5.5.12　平台防注入过滤

为防止应用系统遭受注入攻击，需要严格规范系统的开发规范，从程序开发的过程中杜绝注入攻击的可能性。

主要是有以下两个方面：

5.5.5.13　SQL脚本注入

攻击者往往利用此类注入来非法执行数据库访问，以查看权限范围外的信息，造成信息的泄露。或者利用该注入方式修改SQL语句的逻辑，造成系统数据库级的信息校验的失效。防范此类注入攻击需要在程序开发的时候对涉及数据库JDBC操作的时候禁止使用字符串拼接SQL的方式，同时强制要求采用JAVA的PreparedStatement类来对SQL语句进行预处理，将参数值以方法调用的方式传递给PreparedStatement类。

5.5.5.14　跨站（XSS）及跨站CSRF脚本注入攻击

攻击者可以通过在输入的信息中植入JavaScript脚本，给系统带来界面信息的混乱，甚至通过执行相关逻辑来给系统带来灾难。为杜绝此类注入的危害，需要严格要求在服务端对页面输入信息的合法性进行校验，对需要在页面进行显示的数据项进行JavaScript脚本的校验和处理，切断JavaScript脚本运行的渠道。

脚本可以直接获取用户Cookie信息，如获取JSESSIONID会话ID，最终获取服务端账户登录权限等

在PowerEngine平台中可以通过参数化的方式为系统中的每一类数据设置一个校验规则，称之为“样式”，主要是使用Java的正则表达式技术来实现。通过该样式来对企业网银系统从页面输入的数据进行校验，确保输入数据的合法性。

5.5.5.15　对外接口安全

对外接口支持多种接入方式及支持多种类型的主机系统，严格的参数限定及健全安全检查机制，支持SSL及服务端安全身份认证，确保接口数据规范性及数据传递的安全性。

平台目前支持MD5,DSA,RSA等多种签名算法来对请求参数和响应输出参数进行签名，以实现数据防篡改、数据来源认证及防抵赖。传统的MD5签名方式是对称密钥方式，不满足防抵赖功能特性，且MD5算法容易被破解，在合规以及安全性上都存在风险，应该逐渐废弃。因此，对新开接口，推荐只支持使用RSA或DSA作为签名算法，停止支持MD5的签名方式。

接口涉及传文件时，对上传的文件类型以及大小做限制，上传的文件类型通过content-type以及后缀进行判断。图片上传，需要对恶意代码进行过滤。对于上传的文件应设为只读及不可执行权限等，涉及敏感信息的，需要对访问权限进行访问控制及定期杀毒扫描。

5.5.5.16　认证安全

平台提供了严格的安全认真机制及开发规范，用以防范垂直权限、水平权限、校验饶过及遗留安全等的漏洞检查，主要如下：

5.5.5.16.1　垂直权限漏洞

平台提供了安全模型，防范不同深度权限控制不当，导致没有特定权限的用户仍可以继续操作。

5.5.5.16.2　水平权限漏洞

平台提供了安全模型，用户之前权限控制不足，导致可跨越账户操作其他账户的信息或资金。

5.5.5.16.3　校验饶过漏洞

提供了安全开发、防范规范，防范饶过业务上必须要求的校验，进行业务操作

5.5.5.16.4　权限遗留漏洞

提供了安全开发、防范规范，防范部分页面或者Web服务遗漏权限配置，造成可匿名访问

5.5.5.17　会话管理安全

平台对会话有严格的限制，支持分布式会话，支持分布式环境下，用户会话的无缝恢复等。同时对会话使用有严格的限制，不允许将不安全的、敏感的数据存放在会话中。

5.5.5.18　敏感数据存储安全

涉及敏感数据原则上不允许存储在数据库或打印在日志文件中，如密钥、密码等，如需要，开发平台提供了加解密码算法，支持对称、非对称加解密算法及国密算法等。

5.5.5.19　敏感数据传输安全

平台提供高性能安全加、解密API组件，对敏感数据的传递，支持加密传递，支持单双向SSL，支持敏感数据的传递途中全程不落地。

5.5.5.20　可接入性

平台支持多种客户端设备接入及多种协议、多种数据格式的接入的接入，支持对调用的客户端、渠道鉴权。

5.5.5.21　平台保密性

平台提供安全加密组件安全规范，确保代码、数据的安全。

5.5.5.22　不可篡改性

平台提供客户端签名及服务端验证技术，支持编码及配置的灵活方式，确保数据完整性及不可逆性。

5.5.5.23　代码安全扫描

平台开发工具集成开源的、轻量级的findbugs 、checkstyle、pmd 等eclipse插件,对开发代码做静态检查，它检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。

此类插件，可以简单高效全面地帮助我们发现程序代码中存在的bug，以及潜在隐患。针对各种问题，它并且提供了简单的修改意见供我们重构时进行参考； 通过使用此类插件，可以一定程度上降低我们code review的工作量，提高review效率，提高代码的质量。通过checkstyle插件，可以提高代码的规范性。

5.5.5.24　程序签名

平台提供了签名技术，可对客户端安装包、控件、文件、jar做签名，确保文件的完整性。

6　
客户端vx技术

随着互联网深入发展，应用领域不断拓宽，对于银行领域产生深远的影响，不管是网上银行、手机银行，还是商城、支付，都正在经历Web2.0/Web3.0的快速转变，客户流量从传统PC向手机、PAD等移动设备分流。由于Web2.0对用户界面、用户体验提出了很高的要求，传统的BS结构在新的形势下，需要在客户端进行快速提升，才能满足用户的需要，并逐步提高用户使用的便携性、方便性、易用性等。

从业务角度，前端应用越来越多，急需整合。手机银行、微信银行、直销银行、Wap站点、WEB系统，每个应用都自己一套页面，包括UI、页面流程、交互方式等，不尽相同，同一个业务功能在不同的移动端应用中体验不统一，移动端渠道重复开发，开发维护成功高，APP间某些业务功能页面复用存在交叉调度，呈蜘蛛网趋势。

从技术角度，RIA架构已经提出几年，但目前在银行界刚刚尝试，HTML5标准大大提升了浏览器的能力，也逐步成为浏览器的事实标准。而移动终端（智能手机、平板电脑）的迅速普及，极大促进了UI/UE的发展，基于用户为中心的设计（UCD）也将成为未来客户端的发展主流。

为应对互联网发展新趋势，更好适应Web2.0新技术，科蓝公司在前端技术领域推出前端整合平台，Venus eXtras。

6.0.1　VX客户端体系

VX为满足UI/UE发展的需要，根据对不同技术和方向的综合研究，制定了客户端的发展规划，逐步形成了VX的客户端体系。

根据RIA的整体设计，客户端的开发分为5个层次：

• 内容：Html文本通过Http协议发送。
• 语义结构：通过HTML标签结构定义界面的结构。
• 设计：通过CSS将HTML渲染形成用户界面。
• 行为交互：通过JS控制界面的交互和行为。
• 可用性：通过ARIA的角色定义“组件”结构。

从HTML5的角度来看，除了HTML的新特性外，HTML5定义一套标准的开发方式，即

HTML5 ~= HTML + CSS + JS

其中，HTML：结构 & 内容 & 交互

       CSS：样式 & 动画

        JS：交互 & 样式 & 动画 & 结构 & 内容

（红色黑体为主要任务，其他为辅助任务）

VX整个体系遵循RIA和HTML5设计总体要求，强调HTML/CSS/JS的责任划分，同时通过VX综合能力形成一套强大的、完善的、灵活的客户端架构。

VX采用javascript的纯客户端技术，与现有成熟的Web技术（HTML/CSS/javascript）无缝融合，大大简化了Web App的开发。VX提供了一套高级别的“抽象”模型，整合现有的Web App开发单元，VX自动处理这些开发任务：

• DOM操作。
• Listener和Notifier的注册和初始化。
• 输入校验。

由于VX已经解决很多繁琐的开发单元任务，使得开发者能集中精力在业务处理逻辑，避免大量底层、重复性、易出错的编码工作；同时VX为客户端开发引入一些“高级”的技术：

• 数据、逻辑和展示的分离。
• 数据和展示之间的数据绑定。
• 服务（可复用的Web App操作组件）。
• 依赖性注入（主要解决服务间的依赖关系）。
• 可高度扩展的HTML编译器（纯javascript）。
• 容易测试。

VX可以开发“单页App”或“多页”App，但VX特别适合“单页”App——也就是“富客户端”（RIA）；“单页”App相比“多页”App有着显著的优势，比如：

1. 应用资源一次性加载，避免大量的带宽消耗。
2. App“碎片”（包括HTML和JS）的动态装载和可配置化的缓存。
3. “碎片”间可方便进行数据交换，避免使用服务端Session。
4. 极大提升了Web App的交互性设计的技术基础。

6.0.2　VX框架

VX是开发动态Web App的结构性框架，通过HTML作为模板语言并扩展HTML语法，使得应用组件开发保持高度的清晰和一致。通过独创的客户端“数据绑定”和“依赖注入”，大大减少JS代码量。VX采用纯javascript开发，在浏览器中运行，非常容易与现有的服务端结构整合，是WEB项目开发的好帮手。

HTML是一种声明式的标记语言，特别适合描述静态文档结构，而VX弥补了HTML在动态应用开发中的不足。通过扩展HTML的静态语法，使得HTML成为Web App开发中最简洁、合适的方式。在VX之间，通常为了解决静态文档和动态程序的失配，我们会采用：

程序库：一组web app开发的工具函数，应用根据需要进行调用，比如jQuery（选择使用）。

应用框架：为某类特定的应用而形成的模板类结构，应用需要满足框架的API要求，比如backbone、sproutcore等。

VX采用一种全新的方式，降低了静态HTML和动态Web APP的“阻抗”，通过HTML“指令”扩展浏览器支持的语法，提升浏览器的处理能力，比如：

• 通过{{}}提供文本数据绑定
• 提供DOM结构的循环/隐藏处理
• 提供form处理和数据校验
• 在DOM后隐藏代码
• 将HTML结构形成重用组件

VX提供一个Web App开发的“端到端”解决方案，它提供了应用的整体结构，并便于扩展，特别适用于大多数的“业务处理”类应用，VX提供：

通过依赖注入，提供一套可高度扩展的组件化和模块化架构。

提供完整的MVC结构，包括模板指令、数据绑定、Scope等。

VX内部提供一系列成熟的基础服务，比如表达式、过滤器。

VX内部提供一系列HTML指令，比如form处理、事件处理、循环结构处理、条件结构处理、碎

片化窗口机制等。

通过碎片化窗口机制提供HTML碎片和javascript动态加载方式，为RIA的应用结构打下坚实

的基础。

当然，VX并不是适用于所有的Web App开发，对于某些需要大量操作DOM结构和页面高度交互和动画的应用，比如游戏，可能VX并不能提供一套完整的解决方案（VX的最佳实践表明，在Controller中不宜进行DOM操作，DOM操作应交给HTML指令进行）。

整个应用并没有调用VX的特定API，也没有实现VX的特定行为。我们实现整个应用仅仅是浏览器在静态文档处理的基础上，“增强”了处理动态内容的能力。总之，VX降低了浏览器和应用之间的“阻抗”，无需对框架和库进行直接调用。

6.0.3　VX核心理念

Javascript特别需要“结构式框架”，形成标准的Web App开发模式。根据以往经验，特别是ColdFusion和Flex的客户端编程经验，VX坚持“声明优于编码”的理念，声明式指令可以更好地建立UI并形成组件，而编码更适于业务逻辑的处理，VX坚持：

• DOM操作与应用逻辑分离，这将大大提高代码的可测试性
• 测试与应用编码同等重要，测试难度很大程度上取决于代码的良好结构
• 客户端与服务端代码分离，允许开发并行，实现双方向重用
• 建立完整的开发流程，从UI设计、业务逻辑到业务测试
• 对通常的开发高度重用并简化开发，同时对特定要求提供扩展的可能

通过VX开发，可消除客户端开发的一些常见“弊病”：

• Callback注册：客户端开发采用事件编程模式，其中使用大量的事件“回调”，但分散的回调函数，使得应用的结构模糊和晦涩，同时产生大量的重复编码。
• DOM操作编码：DOM操作时AJAX应用的基础，但异常繁琐，而且容易出错。通过“声明式”的方式将UI与数据绑定，将大大减少甚至杜绝直接的DOM操作，VX应用原则上可以完全不必直接操作DOM（推荐方式），虽然你可以那么做。
• 数据双向绑定：通常处理流程从服务端获取数据，形成model并输出到form，用户修改form并进行数据校验，显示数据校验错误，准确无误后形成model，最后提交服务端。整个过程产生大量编码，VX包括了整个流程，并大大简化编码流程和代码量。
• 大量启动代码：对于典型的“Hello World”AJAX应用，往往需要大量的启动代码。VX通过依赖注入方式，内置提供大量基础服务，使得初始应用异常简单，同时还允许应用对初始化进行干预或定制。

6.0.4　VX应用体系

VX客户端开发自成体系，主要用于智能终端（iPhone、Android手机、iPad、Android Pad）和传统PC桌面的开发，为了完成客户端的开发，VX只是其中最重要的环节，还需要配合HTML规范和CSS规范才能形成客户端的完整的体系，本章从VX应用开发的角度，说明VX开发的主要过程。

6.0.4.1　应用体系

VX的开发体系不能孤立地认为仅仅是VX的代码结构，而是应该结合应用结构和CSS共同完成整个的开发体系，应用结构由HTML结构和VX协同完成。由于VX扩展性可以快速为不同类型应用形成一套规范的结构体系。

VX体系如上图所示，主要分为：

基础层：包括基础 API，VX对它进行扩展，比如提供scope()/controller()等函数，并修订element的remove行为，确保scope正确$destroy；同时VX提供一些公共函数API供外部调用，通过使用这些API可以保证通用逻辑和行为的一致性。

核心层：主要包括模块管理和模块v核心服务、指令和过滤器，模块的核心服务包括$injector（依赖注入管理）和$provide（组件工厂，通过xxxxProvider、xxxxDirectiveProvider、xxxxFilterProvider分别产生服务、指令和过滤器）；模块v包含VX主要的基础组件，构成基础的应用结构，通过扩展模块v或者新建模块可以形成扩展的应用结构。

扩展层：主要为了进一步形成统一的应用结构，扩展成2个层次考虑。一个是通用的扩展（包括服务、UI指令、过滤器）；另一个是为了2大类不同应用进行的专门扩展，包括PC桌面应用扩展和智能移动终端的扩展，可进一步细分为智能手机和平板电脑。

应用层：根据应用不同类型，在统一的应用结构上构建不同的应用系统，包括网上银行、手机银行、移动营销、网上商城等。

6.0.4.2　应用结构

VX遵循HTML5客户端结构原则，一个完整的应用应包含：

• 结构良好、语义清晰的HTML结构：HTML层次关系与应用层次一一对应，比如导航区、应用区、菜单区、边栏区、Header和Footer等，构建合理的HTML结构是HTML5客户端应用的基础。
• 应用功能代码：包含登录和登录控制处理、导航处理、表单及表单元素的统一处理、数据展示（比如表格、列表、分页等），此部分主要与VX结合，完成具体功能。
• 结构化CSS：利用成熟的CSS框架，比如bootstrap，结合应用具体要求，制定CSS样式规范，包括结构样式、交互样式、功能样式、表单样式等。
• 交互式设计：应用的交互式包括功能和流程的优化、动画设计、转场设计、图表设计等多方面的内容，需要结合CSS、JS和VX，各自发挥优势，共同形成“用户体验”的绿色生态。

6.0.4.3　Web 应用

典型的VX应用是一个“单页”的Web App，如下所示：

VX采用碎片化窗口机制模拟“多窗口”应用，在单一的页面中包含

• Header区：该区中包含主导航（Navigation）和系统面板（包含信息、登入、退出等），Navigation可以控制菜单变化，或直接更新主窗口；系统面板可以控制不同的辅助窗口。
• Footer区：该区中包含版权信息、工具面板，根据应用需要工具面板可以和系统面板合并，工具面板可以控制不同的辅助窗口。
• 菜单窗口：该窗口可以选择碎片化窗口机制形式，或者与Header、Footer一样，作为菜单区形式存在；采用碎片化窗口机制形式便于动态加载，而菜单区则为一次性加载；菜单直接更新主窗口。
• 主窗口：主要的应用功能区，根据菜单导航，在不同的功能间切换窗口内容。
• 信息窗口：主要服务于主窗口，根据主窗口的变化“联动”更新信息窗口的内容。
• 辅助窗口：用于辅助功能的实现，主要通过系统面板和工具面板控制，该区也用于与第三方应用集成。

所有的功能区和窗口均为逻辑结构，应用的呈现形式根据CSS样式设定。

7　移动银行系统

移动银行系统，总体架构分为移动客户端和移动服务端两部分，移动客户端主要为客户手机/手持设备上安装的客户端软件，基于统一的Native开发平台开发；移动服务端将主要分为WEB层、APP层和DB层，其中WEB层和APP层为横向扩展的集成架构以满足日后业务交易量日渐增长的需要，方便移动银行功能和服务的扩展。移动服务端受理客户端提交的服务请求，通过移动服务端具体的银行业务逻辑处理模块，处理服务请求并与银行核心系统、其他外围外挂系统进行通讯和信息交互。架构如下：

8　客户端应用软件管理要求

8.1　设计要求 

基本要求：

a) 客户端应用软件设计应遵循安全、可靠、易用、可维护和可扩展等原则，制定用于指导客户端应用软件设计与开发的总体方案。

b) 客户端应用软件应提供易用、风格统一、体验良好的用户界面。

c) 客户端应用软件应遵循合法、正当、必要的原则，不收集与所提供服务无关的个人金融信息。

d) 客户端应用软件收集个人金融信息或用户授权等操作前，要以通俗易懂、简单明了的方式展示个人金融信息收集使用规则，并经个人金融信息主体自主选择同意。

e) 客户端应用软件不得以默认、捆绑、停止安装使用等手段变相强迫用户授权，不得违反与用户的约定收集使用个人金融信息。

增强要求：

a) 客户端应用软件设计在遵循易用性原则的基础上，应采用人工智能技术，其中智能语音交互。

b) 客户端应用软件应提供访问、更正个人金融信息，以及授权撤销功能。

8.2　开发要求 

基本要求：

a) 客户端应用软件开发过程中应遵守严格的开发流程、项目管理流程和编码安全规范，进行完整的测试，避免在请求、响应、存储、配置等功能中存在漏洞。

b) 客户端应用软件开发过程中应建立并维护开发文档。

c) 客户端应用软件开发完成后，应同步完成产品手册、用户手册或提供在线帮助说明功能。

d) 客户端应用软件的每次重要更新、升级，都必须经过严格归档、源代码扫描、发布审核等步骤。

8.3　发布要求 

基本要求：

a) 客户端上线发布，会对应用软件进行签名和加固，升级渠道为应用内升级，下载渠道为安卓各大应用市场。

b) 客户端应用软件已删除调试或测试中存留的敏感数据。

d) 客户端应用软件有新版本时，不能未经用户允许自动安装新版本。

e) 客户端应用软件暂不支持动态模块更新

8.4　维护要求  

基本要求：

客户端应用软件具有明确的应用标识符和版本序号，管理员可通过后台管理系统可进行版本维护，通过更新接口控制客户端应用软件进行增量更新或强制更新操作。