1 标识与鉴别
1.1 身份标识
应用系统的管理员及普通用户应具有明确的身份标识（账号）：
- a) 身份标识应具有唯一性，保证应用系统中不存在重复身份标识；
- b) 身份标识应不可预测，如递增的序列号等；
- c) 将身份标识与审计记录关联；
- d) 应支持角色定义，角色的权限管理，用户的角色管理等；
- e) 授权管理员能够增加、修改、删除账号和角色；
- f) 账号异常时（如登录过于频繁、长时间未登录等），应支持管理员后台锁定用户账号。
1.2 基本身份鉴别
应用系统应对管理员及普通用户的身份进行鉴别：
- a) 应采用至少一种方式对管理员及用户身份进行鉴别：如用户名/密码、USBkey、证书、动态密码等；
- b) 若通过用户名/密码进行鉴别，必须支持：
- 密码长度限制（至少8位）；
- 复杂度限制（如包含字母、数字和特殊字符）；
- 支持弱密码检查，不得使用常见的弱密码，如!QAZ2wsx、test1234等；
- 用户应能修改自身密码，管理员可修改自身密码，用户管理员可重置其它账号密码；
支持密码长度及复杂度要求配置；- 支持密码有效期检查，到达密码有效期后应提醒用户修改密码；
- c) 若采用USBkey、动态密码令牌等进行身份鉴别，应具有PIN码保护；
- d) 对互联网接入的重要系统应采用两种或两种以上的方式进行鉴别。
1.3 重鉴别
执行重要操作或者敏感信息修改时，需对用户进行重鉴别或结合其它途径进行鉴别：
- a) 涉及交易功能、账号重要关联信息（密码、身份证件号、关联的手机号/邮箱等）修改时应对用户再次进行身份认证；
- b) 若支持密码找回功能，需通过账号绑定的手机或邮箱发送随机证码方式进行二次鉴别。
1.4 图形验证码
对于通过电脑自动操作可能会带来危害的页面，需采用验证码措施，防止电脑自动识别：
- a) 至少以下页面需采用图形验证码：注册页面、短信及邮箱认证页面、限时抢购类等；
- b) 图形验证码应采取一定的干扰措施且不可预测，如字体倾斜，加背景噪点、横线等；
- c) 需由服务端生成并进行验证，不得在页面源文件返回；
- d) 验证码应具有有效期，建议为5分钟。
1.5 防暴力猜测
应用系统应具备防止密码、验证码等的暴力猜测功能：
- a)防密码暴力猜测：对采用密码进行鉴别的系统，因防止密码暴力猜测，连续失败登录后锁定账号。账号锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁；
- b)防验证码暴力猜测：若系统具备验证码功能，应具有防止验证码暴力猜测措施。如验证码连续错误一定的次数后，锁定该主机继续猜测或者锁定主机IP地址等。
1.6 鉴别数据保护
应用系统应具备鉴别数据保护功能，具体技术要求如下：
- a) 鉴别数据加密存储；
- 尽可能不在客户端存储密码，若有必要，如cookie中暂存，应以加密方式存储；
- 服务器或数据库中以摘要值方式存储：使用Hash+Salt,使用SHA2及以上强度的Hash算法。
- b) 鉴别数据加密传输：可采用加密的传输通道，或者对密码以摘要方式传输。
1.7 管理安全
应用系统应支持管理员设置可信管理主机的IP地址，仅通过可信主机能够登录应用系统进行管理； 后台管理界面不应向互联网暴露。
1.8 统一认证
**内部、外部人员应采取统一认证：
- a) 内部人员使用的应用系统应采用独立集中认证（SSO）；
- b) 外部人员使用的应用系统应采用独立集中认证（SSO）。
2 授权与访问控制
2.1 访问控制
应用系统应提供基于主体（动作执行者，通常为账号、应用程序等）、客体（动作的受体，如接口、文件、数据、菜单功能等）及操作内容的访问控制功能：
- a) 访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作：
- 主体：应支持用户、用户组，或者依据公司的组织架构；
- 客体：基于业务需求及菜单的各项子功能，如用户管理、权限管理、业务操作、审计管理、数据范围等；
- 操作：应支持可读、读写等。
- b) 访问控制的细粒度应满足业务上最小授权的需求；
- c) 权限控制策略严格有效，防止任何越权操作。任何操作执行前，应对操作主体、客体并依据访问控制规则进行检查。
2.2 权限最小化
应对用户/管理员、数据库连接等应采取最小权限原则：
- a) 不应具有超级账号（同时具有操作、审计等应用系统的全部权限）；
- b) 至少支持将操作用户及审计用户权限分离；
- c) 与数据库连接的账号应为数据库普通权限账号，只能访问允许的数据库和表；
- d) 应用启动进程的权限尽可能小。应用使用的系统账号（运行环境中的）应该有尽可能低的权限。不使用“Administrator”、“root”、“sa”、“sysman”、“Supervisor”或其它所有的特权用户被用来运行应用程序或连接到网站服务器，或中间件。
2.3 禁止默认账号
应用系统不应具有默认账号（固化在应用系统中的账号，且不可修改）。
2.4 统一授权
应用系统应支持集中统一授权。
3 会话管理
3.1 会话超时
应用系统应具有会话超时机制：
- a) 管理界面及业务界面应具有超时退出机制；
- b) 超时时间管理员可配置，交易页面不超过5分钟。
3.2 并发控制
应用系统应对会话并发进行控制：
- a) 应能对系统最大并发会话连接数进行限制；
- b) 应能对单个账号的多重并发（同一账号同时在不同的终端上登录）进行限制，出现重复登录时，给出明确提示；
- c) 应能对系统的连接频率进行限制。
3.3 防重放
应用系统应采取时间戳、序列号等措施防止重放攻击及重复提交：
- a) 防鉴别信息重放：应具备防止通过重放抓取的鉴别数据报文或者cookie绕过身份验证过程；
- b) 防止交易数据重复接收处理：应具备防止因网络因素或人为有意行为的交易数据重复接收处理。
3.4 会话安全
应采取措施保证http（https）的会话安全：
- a) 应保证cookie安全性：如启用HttpOnly属性，使用临时性Cookie取代永久性Cookie，不使用Cookie定制信息，敏感Cookie需加密保存，HTTPS协议下应启用Secure属性；
- b) 用户注销会话后，不能通过使用浏览器的回退按钮来显示；
- c) 用户登录后需要使用新的会话标识，并且会话标识的生成应具有随机性。
4 数据安全
4.1 数据传输安全
应采取措施保证服务器与客户端数据传输安全：
- a) 对于互联网传输的敏感信息应采取加密方式传输；
- b) 互联网传输的BS架构应用应采用VPN链路加密或HTTPS（应采用TLS加密）；
- c) 互联网传输的CS架构应用应采用加密方式传输；
- d) 对涉及资金交易的传输内容应采取完整性保护措施；
- e) 对涉及资金交易的传输内容应采取抗抵赖措施。
4.2 数据存储及展示安全
采取措施保证服务器及客户端存储的敏感信息的安全：
- a) 服务端的敏感数据应保存在数据库中，特别敏感（如身份鉴别数据、客户隐私信息等）的内容应在数据库中加密存储；
- b) 服务端及客户端保存敏感信息的非数据库文件应加密存储；
- c) 非业务上的必要，敏感信息在终端上展示时应做模糊处理，如部分内容以方式传输及显示；
- d) 日志审计记录中不能记录敏感信息，如鉴别信息、完整交易信息、银行卡相关信息等。
4.3 参数保护
应采取措施保证参数安全：
- a) 不得在代码中对敏感信息进行硬编码，如数据库连接参数等；
- b) 必要时需要配置Robots.txt，列出允许爬虫访问范围，防止访问敏感数据；
- c) 使用HTTP POST方法代替GET方法来提交表单，禁止使用表单的隐藏字段来传递敏感信息；不依赖HTTP头信息，对客户端提交的HTTP头进行过滤；
- d) BS应用页面源文件中不得包含敏感信息：如开发人员信息、内部地址及路径等；
- e) 内容安全，如：对公开发布的内容、在论坛或留言时需要对关键字和敏感字进行过滤。
4.4 密钥及加密算法安全要求
应保证秘钥分发存储及加密算法的安全：
- a) 应保证密钥的存储、传输安全；
- b) 密钥保存在终端时应定期更换；
- c) 系统所采用的各类加密算法（对称算法、非对称算法、摘要算法等）应使用安全的加密算法：
- d) 不得使用自定义算法。
5 软件容错和异常管理
5.1 验证方式
应对客户端提交的表单、文件等进行验证：
- a) 对来自系统之外的任何数据进行有效性验证，包括但不限于：客户端提交的任何数据（URL、表单、文件、HTTP协议头等标准协议的扩展内容等）、通过应用 接口接收的数据、通过文件共享/应用接口等主动获取的数据等；
- b) 采用白名单方式进行验证，仅允许规则允许的内容，对无法识别的内容默认禁止；
- c) 可采取客户端对通过人机接口输入的内容进行初步验证方式；
- d) 对所有外部进入的数据均需由服务端进行有效性验证；
- e) 应采用标准的、统一的筛选器对内容进行检查验证。
5.2 限制及验证内容
限制及验证内容应包括以下方面：
- a) 数据的字符类型、长度、格式和范围，防止缓冲区溢出及其他不可预知的异常；
- b) 文件的类型格式、大小等；
- c) 已知的有害输入，如例如“’”,“–”，“&”，“<”,“>”，“/”，“=”，“#”，“\r\n”，“\n\n”，“；”等字符，防止常见的SQL注入、XSS、等攻击行为；
- d) 对常见编码格式进行检查，防止通过转换编码逃避验证。
5.3 异常管理
当系统出现故障时，应避免敏感信息泄露及保存详细错误信息，出现故障时：
- a) 向客户端及人机界面以最小原则反馈出错提示（如错误ID），避免泄露敏感信息；
- b) 系统后台应保存详细的错误信息，足以支持运维人员及开发人员对故障进行分析定位。
5.4 第三方组件安全
应用系统若采用第三方组件（如Apache、tomcat等中间件，数据库，struct2、jQuery、ewebeditor、fckeditor等应用组件，.net、java运行环境等），应保证其安全：
- a) 需从可信途径获取第三方组件的安装程序；
- b) 采用不存在已知安全漏洞的第三方组件版本；
- c) 对第三方组件进行安全加固配置：如删除非必要的默认页面、关闭调试模式、过滤详细的错误信息反馈等。
6 安全审计
6.1 审计事件类型
各应用系统分别进行用户管理过程的日志记录，包括用户的管理行为、登录行为等，确保系统操作行为可追溯，具体如：
- a) 鉴别事件：通过人机界面及应用接口等所有的鉴别事件，包括成功和失败事件；
- b) 用户非授权访问尝试操作；
- c) 账号操作：包括增加、修改、删除等；
- d) 客户数据批量导出操作；
- e) 其它重要操作内容，如数据查询及导出、重要参数修改；
- f) 系统运行事件：系统启动、重启、停止及运行过程中各种可能的异常情况。
6.2 审计内容
每个审计记录中至少记录如下信息：
- a) 事件的主体：如用户、进程名等；
- b) 事件的日期、时间；
- c) 事件来源：如请求的IP地址，MAC地址；
- d) 事件类型；
- e) 事件内容；
- f) 事件结果（可包含在事件内容中）：成功或者失败。
6.3 审计日志管理
应用系统应具备安全审计功能，日志管理要求如下：
- a) 只允许授权管理员访问日志；
- b) 授权管理员支持对日志存档、删除和清空的权限；
- c) 提供能查阅日志的工具，并且只允许授权管理员使用查阅工具；
- d) 提供对审计事件一定的检索能力，检索条件包括时间、日期、主体ID、客体ID等；
- e) 支持以标准格式（如Syslog、SNMP等）方式把日志数据外发到统一日志服务器。
6.4 审计日志分析及告警
涉及交易、支付类的关键应用系统应提供一定的日志分析及告警功能：
- a) 应有一套规则对审计日志进行分析，发现可能存在的异常，如
- 登录异常：非业务时间登录、非可信地址范围内登录、连续登录失败、登录过于频繁等
- 用户行为异常：持续尝试访问非授权内容、业务数据批量导出等；
- 系统状态异常：功能模块异常、并发数异常、服务水平过低等。
- b) 提供分析接口，管理员可自定义分析规则对审计日志进行分析；
- c) 分析出潜在的危害行为应及时向管理员告警：页面告警、弹出对话框、email告警等；
- d) 定期向审计管理员发送统计分析报表。
7 应用安全禁止项
系统页面不应存在以下常见安全漏洞:
- a) 用户注册邮箱或手机短信认证存在被绕过的逻辑缺陷；
- b) 密码找回功能存在被绕过的逻辑缺陷；
- c) XSS及跨站请求伪造（CSRF）漏洞；
- d) 各类注入漏洞（包括SQL注入等）。
8 移动APP安全
8.1 Android客户端
应采取措施保证Android客户端安全：
- a) 反编译保护。在将源代码编译成apk时，应对其进行代码混淆操作,如采用Android sdk自带的proguard或商业混淆软件，以防止apk被反编译成易懂的源码。
- b) 应用完整性检验。应对APP添加自身完整性检测功能，以防御其被第三方非法篡改。如对自身计算哈希值（md5/sha1/sha256）并进行校验。
- c) Activity界面劫持。应对APP添加运行时顶层activity界面检测机制，以防御activity界面劫持攻击。
- d) 内存保护。APP在运行过程中，不在内存中保存用户敏感信息（如卡号、密码等），或将敏感信息加密后保存，并在使用后及时清除。
- e) 动态调试。APP应能够防动态调试，可选择自行开发反调试功能（如检测系统是否运行了常用的调试工具）。
- f) 进程注入。APP应能够防进程注入，开发可选择自行开发防动态注入功能。
- g) 组件安全。应合理设置APP组件的exported属性，防止APP自身不必要的组件暴露。
- h) 软键盘安全。对敏感数据（如密码输入、卡号输入）输入的地方，应开发并调用自定义软键盘，以防御键盘劫持攻击。
- i) 软键盘增强安全。对于使用的自定义软键盘，应使软键盘按键随机分布，且应取消其按键点击回显，或缩短其回显时间。（适用于支付等场景）
- j) 手势密码认证。对于重要的APP，应根据业务需要，添加手势密码认证机制，以防御被非法访问。
- k) 建议自研或采用第三方加壳技术进行保护。
8.2 iOS客户端
应采取措施保证iOS客户端安全：
- a) 应用完整性检验。应对APP添加自身完整性检测功能，以防御其可被第三方非法修改；或者检测iOS设备是否越狱，以进行风险提醒。
- b) 动态调试和注入。APP应能够防动态调试，可选择自行开发反调试功能（如检测系统是否运行了常用的调试工具），或者检测iOS设备是否越狱，以进行风险提 醒。（适用于交易类APP）
- c) 内存保护。APP在运行过程中，不在内存中保存用户敏感信息（如卡号、密码等），或将敏感信息加密后保存，并在使用后及时清除。或者检测iOS设备是否越 狱，以进行风险提醒。（适用于交易类APP）
- d) 软键盘增强安全。对于使用的自定义软键盘，应使软键盘按键随机分布，且应取消其按键点击回显，或明显缩短其回显时间。（适用于支付场景）
- e) 手势密码认证。对于重要的APP，应根据业务需要，添加手势密码认证机制，
8.3 客户端数据安全
应采取措施保证客户端数据安全：
- a) 数据文件安全。应当不在APP客户端本地文件保存用户敏感数据（如密码、卡号、证件号等），或者采用安全加密算法（如AES/SHA256等）加密后再保存；
- b) 数据库安全。应对数据库添加访问口令，防御其他APP的直接访问；
- c) 应用日志安全。在APP编译打包成正式安装包时，应删除或注释掉源代码里的日志打印语句，以防止不必要的日志信息泄露。
8.4 通信安全
应采取措施保证App通信全：
- a) 通信加密。应使用加密通信通道（HTTPS)进行用户敏感信息（如登录密码、交易密码等）的传输。
- b) 关键字段单独加密（增强要求）。对于需要传输的敏感或重要的字段信息（如登录密码、交易密码、卡号等），应进行加密（如AES、 SHA256等）后再进行传输。
- c) 数据包完整性校验（增强要求）。对重要通信数据包（如转账、交易等），应对数据包进行完整性签名，并在服务端进行校验，以防止传输过程中被篡改。
- d) 证书合法性校验。当APP采用HTTPS协议进行数据传输时，APP应对接收到的TLS证书进行合法性校验（适用于转账、交易等场景）
8.5 密码策略安全
应采取措施保证密码策略安全：
- a) 密码复杂度测试。 应根据业务需要，在服务端后台添加密码复杂度检测机制，如限制密码长度、大小写、特殊字符等。
- b) 帐号锁定策略。应根据业务需要，在服务端后台添加账号登录失败锁定机制（如连续登录失败5次即锁定），或在登录页面处添加图形验证码机制，以防御暴力破解攻击。
- c) 帐号登录限制。应根据业务需要，在服务端后台添加账号登录检测机制，限制同一账号的多终端同时登录。
8.6 APP服务端安全
服务端安全参照5.1～5.7要求。
9 微信应用安全
对于微信应用，应严格检查提交的请求及接口的安全：
- a) 接口安全：应保证接口安全，防止非授权对象调用；
- b) 以白名单方式对来自接口的任何请求数据，禁止任何不能识别的内容。
- 服务端安全参照5.1～5.7要求。*
10 大数据系统安全
大数据系统，应采取以下措施保证其安全：
- a) 可扩展性：系统设计上应具有良好的扩展性，可根据业务需要增加节点，业务数据能够自动迁移；
- b) 冗余部署：业务数据应冗余存储，单节点故障不影响系统的正常运行，且不会导致数据丢失；
- c) 数据筛选：对进入系统的数据依据相应的规则进行检查，去除无用数据；
- d) 去隐私化：对非业务上必要的隐私数据，如身份证、客户详细信息等，应采取一定的去隐私化处理；
- e) 监控平台：应相应部署大数据库监控平台，对系统的运行状态等进行实施监测。
- 服务端安全参照5.1～5.7要求*
