H5 APP安全风险及解决方案

H5 APP安全风险及解决方案

目录

一.

二.

三.

四.

4.1

4.2

HTML5 概述 ..................................................................................................................................... 3

HTML5 应用开发模式 ..................................................................................................................... 4

H5 应用架构分析 ........................................................................................................................... 5

H5 应用安全风险 ........................................................................................................................... 6

H5 应用面临的安全风险 ..................................................................................................... 6

针对移动应用的攻击 ........................................................................................................... 6

静态攻击 ..................................................................................................................... 6

动态攻击 ..................................................................................................................... 7

4.2.1

4.2.2

4.3

4.4

五.

5.1

5.2

个人信息违规收集 .............................................................................................................. 7

安全建设目标 ...................................................................................................................... 8

H5 应用安全解决方案 SDK ........................................................................................................... 9

SDK 授权安全 ..................................................................................................................... 9

客户端程序安全 ................................................................................................................ 10

客户端程序保护 ........................................................................................................ 10

客户端程序签名 ........................................................................................................ 10

移动客户端运行环境安全 .......................................................................................... 11

数据存储安全 ............................................................................................................ 11

数据交互安全 ............................................................................................................ 12

资源管理 ................................................................................................................... 13

SSL/TLS 安全配置.................................................................................................... 13

客户端证书有效性校验 .............................................................................................. 14

数据传输安全 ............................................................................................................ 14

SDK 授权 ................................................................................................................... 15

身份安全认证 ............................................................................................................ 15

短信验证码安全 ........................................................................................................ 18

访问控制 ................................................................................................................... 18

应用接口安全 ............................................................................................................ 19

数据交互安全 ............................................................................................................ 19

数据存储安全 ............................................................................................................ 22

个人信息安全 ........................................................................................................... 23

运营者对用户权利的保障 ........................................................................................ 24

5.2.1

5.2.2

5.2.3

5.2.4

5.2.5

5.2.6

5.3

5.3.1

5.3.2

5.3.3

5.4

5.4.1

5.4.2

5.4.3

5.4.4

5.4.5

5.4.6

5.4.7

5.5

5.5.1

5.5.2

通信安全 ........................................................................................................................... 13

服务器端安全 .................................................................................................................... 15

个人信息安全 .................................................................................................................... 23

- I -

一. HTML5 概述

网页技术（B/S）是互联网技术在各个行业业务应用的广泛和重要的技术领

域，HTML5 是基于兼容性、实用性、互通性以及通用访问性的理念设计而成

的，随着 HTML5（以下简称“H5”）的发布和应用，H5 已经成为了互联网全新

的框架和平台，包括提供免插件的音视频、图像动画、本地存储以及更多酷炫而

且重要的功能，并使这些应用标准化和开放化，从而能够轻松实现类似桌面的应

用体验，并且，H5 的最显著的优势在于跨平台性，用 H5 搭建的站点应用可以

兼容 PC 端与移动端、windows 与 Linux、安卓和 iOS，它可以轻易地嵌入到各

种不同的开放平台、应用平台上。

二. HTML5 应用开发模式

目前主流的应用程序大体分为三类：Web APP、Native APP 和 Hybrid

APP。

 Web APP：指采用 H5 语言写出的 App，不需要下载安装。生存在浏览

器中的应用，基本上可以说是触屏版的网页应用。

 Native App：指的是 Android 或 iOS 原生应用程序，一般依托于操

作系统，具有较强的交互性和体验性，可拓展性强。需要用户下载安装使用。

 Hybrid App：指的是半原生半 Web 的混合类 App。需要下载安装，看

上去类似 Native App，但只有很少的 UI 组件，通过 WebView 组件加载

H5 页面，展示 Web 内容。

三种开发模式的优缺点对比如下表所示：

特性

开发语言

Web APP Native APP

基于的操作系统

不同，实现的语

言不同，Java

和Object-C 语

言居

多

Hybrid APP

使用 Web 开发语

言即可

展示界面通过 H5

设计，交互通过

Native 语言实

现

代码移植和优化

访问针对特定设

备的特性

充分利用现有知

识

高级图形

升级灵活性

高

低

无

高

高

中

高 低 高

中

高

高

低，需要通过应

用商店或自检测

下载升级包升级

中

中，可局部更新

和应用商店更新

安装体验

中，通过移动浏

览器安装

高，从应用商店

安装

高，可从应用商

店安装

三. H5 应用架构分析

一般来说，当前大部分“混合型 H5 应用”采用如下技术结构：

在这种模式下，服务器端通过其控制的“原生逻辑处理”调用服务端的H5 脚本，

在“浏览器控制”中展示 H5 页面。在此模式下，相关组件控制方包括：

 服务端控制的组件：H5 页面脚本、服务接入端；

 可能为第三方的控制组件：原生界面控件、原生逻辑处理、浏览器控件；

 通用组件：操作系统

四. H5 应用安全风险

移动应用作为个人生活、办公和业务支撑的重要部分，也面临着来自移动平

台的安全风险，不仅仅来自于恶意程序、恶意代码，更多的是恶意的攻击行为、

篡改行为和钓鱼攻击。由于 Web APP 通过移动浏览器加载显示页面以及与服务

器端进行数据交互，面临攻击风险的是服务器端，因此，下方小节所讲述的针对

移动应用攻击不包括 Web APP。

4.1 H5 应用面临的安全风险

在“非加固”的“混合型 H5 应用”场景中，会出现以下的信息安全风险：

 客户端安全

 通信安全



服务器安全

4.2 针对移动应用的攻击

从整体上来说，针对移动应用常见的攻击手段主要有静态攻击和动态攻击两

种。

4.2.1 静态攻击

静态攻击通过对发布的应用进行静态分析，使用反编译及逆向工程分析的手

段，发现并利用应用的脆弱点，对目标用户进行攻击。攻击流程如下图所示：

攻击者将篡改后的应用重新投放市场，当使用者下载安装后，就会面临被攻

击的风险，轻则泄露个人信息，重则导致资金损失。

4.2.2 动态攻击

动态攻击是攻击者通过对应用动态调试的方式，使用注入（代码注入或进程

注入）或者修改内存数据，达到对用户或者服务器攻击的目的。攻击流程如下图

所示：

攻击者通过动态调试，可达到如下攻击目的：

 通过动态调试，分析应用处理逻辑，达到绕过认证的目的；

 通过动态调试，hook 关键函数，篡改提交数据，提交至服务器端，对

服务器进行攻击，如 SQL 注入。

 通过监测目标应用，对目标应用进行界面劫持，达到钓鱼的目的。

4.3 个人信息违规收集

有关个人信息收集应符合《移动互联网应用程序（App）收集使用个人信息

自评估指南》、《App违法违规收集使用个人信息自评估指南》、《App违法违

规收集使用个人信息行为认定方法》、《（工信部信管函〔2019〕337号）和工

信部信管函〔2020〕164号》、《APP用户权益保护测评规范》等有关标准要求。

4.4 安全建设目标

移动应用在整个业务中扮演越来越重要的作用，针对移动应用所面临的风

险，需要建立一套针对 H5 应用的，适应未来发展需求的安全体系，应达到如

下目标：

技术加固：

 减少移动客户端开发阶段引入的漏洞缺陷；

 强化移动客户端应对各种攻击的能力；

 强化授权认证的能力；

应用管理：

 明确各业务场景的安全风险，制定各安全场景下的业务开展模式；

 制定安全开发规范，将安全风险解决于开发阶段。

 建立持续的移动应用安全体系。

五. H5 应用安全解决方案 SDK

5.1 SDK 授权安全

基于业务需要，将自身业务封装为 SDK 供第三方应用接入，在接入过程中，

需要保证自身业务系统的安全性。

定制开发的 SDK，应实现如下功能：

 敏感信息加密：针对前端页面传入的敏感信息（如密码等），对信息加密

后再传入服务器端。

 终端信息提取：提取终端信息，包括但不限于 device id、mac 地址、

app 应用相关信息等，用于服务器端信息认证。

 数字证书认证：验证服务器端证书有效性，防护中间人劫持。

 网络封包：将前端页面提交到服务器端的数据，通过 SDK 进行封包处理，

由 SDK 发送至服务器端，获取返回信息后，再由前端页面显示。

 SDK 加固：SDK 在发布时，应对自身进行代码混淆处理。

第三方接入应用在访问相关业务时，应完成授权流程并嵌入 SDK 完成业务接

入。对于无法嵌入 SDK 的应用，如“微信”应用，应通过业务应用管理进行风险

防范。

 在此种业务场景下不开展“资金交易”等重要业务，以防止中间人攻击，

对请求进行非法篡改。

 不应支持展示包含“高级别敏感信息”页面和相关请求，防范敏感信息泄

露。

5.2 客户端程序安全

5.2.1 客户端程序保护

客户端程序应具备抗逆向分析、完整性校验等安全机制：

方案一

 代码混淆

方案二

对客户端程序进行加壳，提供

技术措施

 具备运行时检查机制，防止

抗逆向分析、代码保护、资源

攻击者对应用程序进行动态

加密等保护。

调试

 具备签名验证机制

 对于 Android APP 的重要

操作 Activity，防范

Activity 劫持

 对于敏感信息的输入（如密

码），使用自定义随机键盘防

范键盘劫持。

5.2.2 客户端程序签名

客户端应用程序以及升级程序在发布时，使用签名专用证书对应用程序进行

签名，保证来源可靠性。

 对应用程序、更新程序、代码文件进行签名，保证应用程序完整性，其

中签名文件必须是自己的签名，禁止使用第三方签名。

 应用程序启动、更新时，客户端应检查升级包的签名是否合法，如果签

名相同，则进行后续操作；否则，应提示用户存在风险，并终止升级过

程。

5.2.3 移动客户端运行环境安全

当用户设备处于 root 状态下，APP 的私有目录

/data/data/$package_name 是可以被任意访问的，当一些恶意程序在获取

root 权限后，就可利用赋予的权限来窃取用户的隐私信息（如短信息、用户键

盘输入等），或者通过遍历客户端的私有目录获取用户的私有信息。因此，系

统在启动或者进行敏感操作时， 应给予处于 root 状态的设备用户风险提示。

在客户端应用启动时，应判断系统是否已 root 或者越狱，并给予用户提示风

险。

1. Android 设备 root 状态检测

可通过检查如下文件列表中的文件是否存在来检测设备的 root 状态：

/system/bin/su

/system/xbin/su

/system/sbin/su

/sbin/su

/vendor/bin/su

2. iOS 设备越狱状态检测

可通过判断设备中是否存在 、、bash、

apt、

sshd 等文件来检测 iOS 设备的越狱状态，具体文件所存放的目录如下表所示：

/Applications/

/Library/MobileSubstrate/

/bin/bash

/usr/sbin/sshd

/etc/apt

5.2.4 数据存储安全

为防范敏感信息和重要信息等用户的隐私数据泄露，客户端应用程序应严格

限定客户端敏感数据存储。

1. 客户端应用中禁止以任何形式保存敏感信息（如明文密码），包括但不限于

代码、内存、本地文件和本地数据库；

2. 对于重要信息，原则上应存储于内存中，仅在应用运行生命周期内有效；

3. 如果客户端需要存储重要信息与文件或者本地数据库中，应使用对称加密算

法对数据进行加密存储，由于加密密钥不能在客户端明文保存，需要使用客

户端数字证书公钥加密或者保存在服务器端：

客户端使用用户数字证书，具体实现流程如下：

1) 用户登录系统，完成身份认证；

2) 使用用户数字证书私钥对本地存储的加密密钥解密；

3) 使用解密后的加密密钥对数据解密。

客户端没有用户数字证书：

1) 用户登录系统，完成身份认证；

2) 与服务器端完成握手，获取密钥对本地存储的加密的密钥进行解密；

3) 使用解密后的加密密钥对数据解密。

4. 对于 Android 客户端应用，在本地文件或者本地数据库中存储重要信息时，

应严格限制 Activity、Service、Broadcast Receiver、Content

Provider 的访问权限，不需要对外部应用提供服务时，应关闭导出接口，

将 exported 属性设置为 false。

5.2.5 数据交互安全

5.2.5.1

敏感数据输入保护

对于用户在客户端程序中输入的敏感信息，包括但不限于用户密码、交易密码、

手势密码等，均应对数据进行安全保护。

1. 对于用户输入的敏感信息及重要信息，客户端程序应采取安全措施防止数据被

窃取，使用软键盘输入控件保护用户输入的敏感信息及重要信息，密码键盘需满

足如下要求：

1) 键盘键位随机布局。

2) 不回显用户输入，通过声音或者震动的方式给予用户反馈。

3) 用户输入字符经过对称加密处理后再存放于内存中，加密密钥从服务器端

获取。

4) 防截屏恶意程序：应用程序应具备防范截屏恶意代码的功能，避免攻击者

通过屏幕截取获得用户密码等敏感信息。

2. 客户端应用程序在重新切入时，应校验手势密码（由于手势密码易被破解，结

合业界实践，建议手势密码仅用于应用屏幕解锁功能），防止用户信息泄露，

手势密码应满足如下安全要求：

1) 在设置手势密码时，应检测手势密码的强度，至少包含 3 个键位。

2) 键位相关数据应先进行哈希处理再存储在客户端。

3) 手势密码软键盘在划过时，应不显示轨迹，以震动的方式给予用户输入反

馈。

5.2.5.2

数据操作安全

对于用户输入数据，为保证用户的友好体验，客户端配合服务器端对数据合法性

进行验证，最终的数据安全校验应由服务器端完成。

1. 对于可枚举数据格式，客户端应校验数据格式的合法性。

2. 客户端应对用户输入数据的安全边界进行检查，如整型数据的大小，字符串类

型数据的长度。

5.2.6 资源管理

客户端在资源操作结束时，如内存操作、文件操作等，应释放资源防止客户端资

源泄漏。

5.3 通信安全

5.3.1 SSL/TLS 安全配置

涉及敏感信息和重要信息传输的客户端和服务器端通信过程，应使用 https 安

全通信协议或参考 TLS 协议建立安全信道，保障通信安全，数字证书以及所采取的

协议应满足如下要求：

（1）数字证书安全

1) 数字证书由可信 CA 签发；

2) RSA 算法密钥长度至少为 2048 bit；

3) 保证签名算法的强度，禁止使用 SHA1 的 SSL 证书，正在使用的 SHA1

证书建议将算法升级至 SHA256；

4) 私钥应在可信安全主机生成，当私钥被泄露时，应立即重新生成私钥并

替换旧私钥；

5) 自签名的证书为用户产生的证书，没有在权威机构（CA）注册过，不能

确保它的真实性，但可以保证数据传输的安全性，因此只能用作加密而

不能用于身份认证。

（2）协议安全

1) 使用安全的协议，禁止使用 SSL v2 和 v3，建议使用 TLS v1.2；

2) 使用安全的加密套件：

a) 对称加密密钥建议长度为 128 位以上；

b) 禁止使用 RC4 加密算法；

c) 禁用 MD5、SHA1 哈希算法。

5.3.2 客户端证书有效性校验

移动客户端和服务器端通信时，应首先校验服务器端证书的有效性，防止中

间人攻击导致敏感数据泄露。

（1）基于浏览器校验证书的行为，证书需要采用权威机构（CA）认证的证

书，自有证书浏览器无法通过校验；

（2）移动端 APP 按照以下要求进行校验：

 客户端校验完整的证书链，验证服务端证书是否合法，是否在有效期

内，域名信息是否和实际信息一致。

 如果服务端使用自签名的证书，应在客户端预植 CA 根证书或服务器端

数字证书，在通信时校验服务器端证书的有效性，确保通信安全。

 当使用内置的浏览器组件（如移动 APP 的 WebView 组件）加载 https

页面时，如发生证书认证错误，应直接终止页面的加载。

5.3.3 数据传输安全

（1）对于涉及敏感信息和重要信息传输的应用系统，应配置完善的基于服

务器证书单向认证的 TLS 安全信道，保证通信数据的安全性。

a) 客户端验证服务器端证书有效性，防护中间人攻击。

b) 在单向认证的 TLS 安全信道基础上，基于数字证书遵循 TLS 协议标准

实现双向认证的安全信道建立和数据加密。

c) 在应用系统中提交重要操作时，结合业务场景，在客户端使用数字证书

对传输的操作数据签名，在服务器端验证签名的有效性，以保证数据的

完整性。

5.4 服务器端安全

5.4.1 SDK 授权

为合作的第三方渠道提供嵌套运行的 SDK 时，应严格依照授权流程，对第

三方公司进行授权。

外部接入的客户端程序在接入时，服务器端应验证 SDK 授权的合法性。

对于应用客户端直接接入服务器的模式，验证流程如下：

（1）客户端获取自身标识，标识由与第三方公司共同定义，由授权码、

应用包名以及应用签名组成，提交至服务器端。

（2）服务器端接收到授权请求，验证标识是否为合法的第三方应用授权。

（3）若为合法授权应用，则建立通信信道，与客户端通信，否则，终端

通信连接。

若移动应用客户端通过第三方运营服务器与服务器对接，应做到如下安全控

制：

（1）第三方合作公司应保证客户端有效性的验证。

（2）第三方合作公司应保证授权标识不被泄露，包括但不限于授权码、授

权及签名相关私钥。

（3）第三方应用服务器将数据转发至服务器端时，应保证数据的安全性。

（4）服务器端在接收第三方应用服务器请求时，验证是否为合法授权，请

求的有效性。

5.4.2 身份安全认证

5.4.2.1

会话安全

Session 安全管理

 Session 应具备超时机制，会话超时时间由业务系统定义。如果用户一

定时间无任何操作，服务器端应注销用户会话。

 用户登录时，应生成新的 Session ID。

 用户登录并建立一个会话时，若发现此用户有旧会话，建议注销旧会

话。

会话绑定

在用户登录、修改密码、交易等重要操作场景，对用户会话下用户的设备信息是

否变化做判断。

（1）基于设备指纹实现的会话绑定技术验证逻辑

1) 客户端在发起重要业务请求时，携带获取到的设备指纹发送到服务器端，

服务器端验证客户端设备指纹，判断当前用户请求是否合法：

a) 若当前会话下存在设备指纹，则进行校验，若不匹配，则可判定为不

合法请求，要求用户重新登录，登录后重新绑定设备指纹；

b) 若当前会话下不存在设备指纹，则判断用户是否处于登录状态，若处

于已登录状态，则属于不合法请求，要求用户重新登录，登录后重新

绑定设备指纹；

c) 若用户发起登录请求，服务器端未存储用户设备指纹信息，则登录后

绑定设备指纹。

2) 当前会话下，如果客户端设备信息发生变化时，应强制注销当前会话。

（2）获取设备指纹信息的方法

1) 对于 Android 客户端应用，可通过设备中获取的 device ID、Pseudo-

Uni que ID、mac 地址、cpu number、系统版本等信息进行计算（hash 处

理） 得到唯一标识字符串，然后与用户会话绑定。

2) 对于 iOS 客户端应用，可通过获取 IDFA、IDFV、UDID、系统版本号等设

备标识，然后经过计算（hash 处理）后得到唯一标识字符串，然后与服务

器端用户会话进行绑定。

对于 web 应用，可通过浏览器的信息（如：User Agent、语言、颜色深度、

屏幕分辨率、时区、是否具有会话存储、是否具有本地存储、是否具有索引

DB、IE 是否指定 AddBehavior、是否有打开的 DB、CPU 类型、平台、是否

DoNotTrack、已安装的 Flash 字体列表、Canvas 指纹、WebGL 指纹、浏览

器的插件信息、是否安装 AdBlock 等）计算哈希，得到用户浏览器端的唯一标

识与当前用户会话进行绑定，防止会话盗用。

防会话重放

目前有效的防会话重放的方式有序列号、时间戳、HMAC 挑战应答认证方

法，应用系统在设计时，根据业务系统设计需求进行选择。

（1）对于一般重要场景，可采用序列号、时间戳方式防会话重放。

1) 序列号

a) 通信双方在初次建立通信时协商一对初始序列号，并约定序列号递增

算法（如序列号+1）；

b) 客户端每次发起请求时，通过约定算法对序列号处理，把序列号和业

务数据一起发送给服务器端，服务器端通过本地存储的序列号经过运

算后与客户端请求序列号进行对比验证；

c) 验证通过后，进行业务操作；

d) 客户端也用同样的方式验证服务器端的响应序列号。

2) 时间戳

a) 客户端每次发起请求时，获得系统时间戳，把时间戳和业务数据一起

发送给服务器端。

b) 服务器端获得系统时间戳，跟客户端发送过来的时间戳做对比，如果

时间差在指定的范围内，则验证通过。

（2）对于安全级别较高的业务操作（如转账、交易等请求），应使用数字

证书和随机字符串签名做挑战应答的方式防护重放攻击，如果不能应用数字

证书， 建议使用 HMAC 挑战应答的方式，保证提交数据的安全

HMAC 的一个典型应用是用在“挑战/应答”（Challenge/Response）身份认

证中。以登录为例，认证流程如下：

1) 先由客户端向服务器发出一个验证请求。

2) 服务器接到此请求后生成一个随机数并通过网络传输给客户端（此为挑

战）。

3) 客户端将收到的随机数作为密钥（K），对用户数据（text）进行 hmac

运算，然后将运算结果作为认证提交给服务器端（此为应答）。

4) 与此同时，服务器也使用该随机数与存储在服务器数据库中的该客户数

据进行 HMAC 运算，如果服务器的运算结果与客户端传回的响应结果相同，

则认为客户端是一个合法用户。

用户认证尝试超限锁定

应用系统应具备用户认证失败处理机制，同时提供尝试次数参数设定功能，在

用户身份认证（登录、密码重置等）、交易等重要业务场景下，对密码输入错误尝

试次数进行限制，用户认证超限锁定应满足如下要求：

 把用户的 session 与高危业务、尝试次数、锁定时间进行关联，形成映

射关系表进行保存。

 单位时间内（如 1 小时）用户身份认证尝试失败超过指定次数（建议不

超过 5 次）时，进行用户锁定，锁定时间不低于 10 分钟。

5.4.3 短信验证码安全

对于使用短信验证码作为双因素认证的业务场景，为了保证用户的体验以及系

统的安全性，应满足如下要求：

（1）短信验证码长度不低于 6 位。

（2）为防止短信炸弹攻击，应该限制短信验证码的发送时间间隔和次数，建

议间隔时间大于 60s，每小时内对同一个手机号发送短信的次数不超过 3 次。

（3）应该规定短信验证码的有效时间和输入错误次数，通常情况下有效时间

不长于 60s，输入错误次数不高于 3 次，超出后立即清空验证码。

（4）程序应该判断短信验证码的发送手机号是否为用户绑定的手机号码。

（5）短信验证码一次有效，在验证通过后，应立即清空服务器端会话中保存

的验证码。

5.4.4 访问控制

5.4.4.1权限控制

（1）权限控制要求

1) 对于客户端发送的业务请求，服务器端应判断当前登录用户对请求资源

的访问权限进行验证；

a) 验证当前登录用户是否具有请求 url 的访问权限；

b) 验证当前登录用户是否具有对提交的请求参数的访问及控制权限，如

操作识别码，操作数据等。

2) 权限控制标识必须存储在可信数据源中，如 session、数据库、配置

文件。

（2）授权管理要求

1) 依据最小授权原则，系统对用户应在其业务功能范围内分配最小权限；

2) 依据权限分离原则，将用户管理和用户授权进行权限分离，由不同的操

作用户承担，防止权限滥用。

a) 管理权限用户所进行的操作，应由业务授权用户进行授权后才可生

效；

b) 业务授权用户不具备管理权限。

5.4.5 应用接口安全

应用程序通过接口为外部系统提供数据服务时，应对接口访问进行控制。

（1）用户服务接口验证调用者的身份及权限，判断访问者是否具有接口的访问权

限以及对请求数据的操作权限（判断请求数据是否属于当前登录用户）。

（2）对接口访问频率进行限制，防止恶意攻击堵塞接口。

5.4.6 数据交互安全

5.4.6.1

SQL 注入攻击防护

应用程序在进行数据库操作时，原则上禁止通过参数拼接的方式编写 SQL

语句，防范 SQL 注入攻击。

（1）对于包含用户提交参数的 SQL 语句应通过参数化查询的方式进行处理；

（2）对于确需采取拼接进 SQL 语句的参数，应对传入的数据依据数据库类

型进行有针对性的转义处理。

5.4.6.2

跨站脚本攻击防护

对于服务器端输出到浏览器端的数据，应依据数据输出到页面的不同场景进

行针对性的编码处理，防范跨站脚本攻击对用户造成的影响。具体处理方式如下表所

示。

上下文场景

编码处理

输出到 HTML 标签之间的数据

调用 Html 方法对输出数据

做 HT

ML 实体编码处理

输出到 HTML 标签的属性值的调用 ForHtmlAttr 方法对

数 输出数

据 据进行转义处理

输出到 JavaScript 数据域中调用 JS 方法对输出数据

的数 进行 Jav

据 aScript 转义

调用 URL 方法对输出数据

输出到 URL 参数中的数据

做 UR

L 编码处理

输出到 XML 节点及节点属性调用XML 方法对输出的数据

值中 做编

的数据 码处理，防范 XML 注入

输出到 CSS 样式表中的数据

调用CSS 方法对输出的数据

做转

义处理

为不影响用户体验以及保证安全，调用

输入为富文本内容的数据

CleanRichHt

afeHtml 方法对输入的富文本内容

做过滤处

理

5.4.6.3

上传文件安全

对于提供文件上传功能的应用，应保证上传文件格式的合法性以及文件存储

的安全性。上传文件的合法性校验由服务器端实现，防止绕过客户端程序校验机制上

传恶意文件。

（1）上传文件合法性校验

1) 明确允许上传文件的格式、文件大小、允许上传文件类型，对上传文件的

合法性进行基础校验。

2) 对于特定格式的文件，可依据文件的特性进行有针对性的校验。如：若上

传文件为图片格式，可通过获取图片文件的长宽像素值来判断上传图片文

件是否合法。

3) 结合业务需求，对文件格式、内容可进行增强安全校验。

（2）文件安全存储

1) 将上传文件随机重命名或在源文件名后增加随机数进行重命名后再进行

保存；

2) 上传文件应存放于中间件不做脚本解析的目录（如 web 应用程序之外的

目

录或独立的文件服务器），防止中间件对上传的文件解析执行。

3) 上传文件禁止具有可执行权限。

5.4.6.4

防范路径遍历攻击

在文件下载或者文件查看等功能时，应通过映射文件路径或者判断请求下载

文件的真实路径是否合法来保证服务器端文件访问的安全性，防范攻击者通过路

径遍历攻击的方式获取系统敏感数据。

（1）映射文件路径下载文件

1) 在文件上传时，将文件保存的路径存储于数据表中，使用 ID 与文件路

径建立映射关系；

2) 在用户请求下载文件时，在请求参数中携带文件 ID，服务器端根据文件

ID 来获取真实的文件路径，然后将文件内容返回客户端；

3) 为防范攻击者通过遍历文件 ID 参数的方式下载所有文件，文件 ID 应设

计为通用唯一识别码（UUID）格式。

（2）文件真实路径判断

在用户请求下载文件时，服务器端判断请求文件的真实路径是否属于服务器

端指定保存文件的路径来判断下载请求的合法性。

5.4.6.5

防范 XML 注入攻击

（1）防范 XML 数据注入

从请求参数中获取数据，拼接进 XML 数据的节点或节点属性值中进行处理时，

应对输入输出的 XML 数据进行输出转义。

防范 XML 外部实体注入

对于客户端提交的 XML 格式的数据，服务器端在解析时，应限制DTDs

（doctypes）参数的解析，防止XML外部实体注入导致服务器端敏感信息泄露。

5.4.6.6

HTTP 响应分割

从用户请求报文中获取到的数据（包括请求参数、http header 中的数据、

cookie 以及从接口中获取到的数据），若需写入 http 响应报文头部区域中，

应移除r 和n 字符，防止 http 响应分割攻击对用户造成影响。

5.4.6.7

防范用户隐私信息泄露

为了保证用户敏感信息的不被攻击者窃取利用，系统应通过对敏感信息进行

遮盖的方式保证数据的安全。

为了保护用户隐私，应该采用不完全显示的方式展现用户敏感数据，例如：

数据类型

真实姓名

身份证号

数据内容

姓名

身份证号码

不完全显示方式

姓后面用*代替

身份证号码中间10位数用

*号代替

手机号

手机号码 手机号码中间6位用*号代

替

5.4.6.8

HTTP 请求方法安全

为了保证服务器资源遭到恶意访问和破坏，建议 HTTP 方法仅用 GET 和 POST，

禁用OPTIONS、DELETE、PUT、HEAD 方法。

5.4.7 数据存储安全

5.4.7.1

加密算法应用

在选择加密算法时，根据具体应用场景选择对应安全的加密算法。

算法类型

对 称 加 密 算

法

填充模式 推荐算法 推荐应用场景

交易数据传输、口令传

输

ECB/CBC/C

SM4、AES、3DES

FB/OFB

非 对 称 加 密

算法

哈希算法

— SM2、RSA 身份认证、交易密码传

输

— SM3、SHA256 数据库中密码存储

5.4.7.2

数据存储安全

为了保证数据的完整性、可靠性和机密性，确保只有合法的用户或应用程序

才可以访问被加密的数据和文件。安全要求如下：

 对于应用程序配置文件中所存放的密码等敏感数据，应使用对密码加密处理

后再保存到配置文件中，密钥和加密密码需存储于不同的路径中。

 用户密码等敏感数据在存入数据库时，应使用提供的安全哈希算法，如

SHA256，对用户密码并进行加盐哈希处理后再行存储。

5.5 个人信息安全

5.5.1 个人信息安全

APP存在收集个人信息的行为，应说明个人信息控制者的主体身份、联系方

式、存储期限、存储区域、更正、删除个人信息、注销账号的方法等内容。

（1）应告知用户收集个人信息的目的、方式、范围且未经用户同意，不得

私自收集用户个人信息。

（2）实际收集的个人信息类型不得超出隐私政策所描述范围。

（3）前台收集个人信息的频度不得超出业务功能实际需要。

（4）后台收集个人信息的频度不得超出业务功能实际需要。

（5）若通过嵌入第三方代码插件收集个人信息的功能，应向用户明示。

（6）未经用户同意，不得将收集到的用户搜索、浏览记录、使用习惯等个

人信息，用于定向推送或广告精准营销，同时，要提供关闭该功能选项的行为。

（7）清晰说明各项业务功能及所收集个人信息类型，业务功能与所收集的

个人信息类型应一一对应。

（8）清晰说明个人信息处理规则及用户权益保障，不得在隐私政策文件中

设置不合理条款。清晰说明包括但不限于以下条款：

 APP运营者的基本情况

 个人信息存储和超期处理方式

 个人信息出境情況

 个人信息安全保护措施和能力

 对外共享、转让、公开披露个人信息规则

 用户权利保障机制

 个人信息的展示限制

 用户申诉渠道和反馈机制

 隐私政策时效

5.5.2 运营者对用户权利的保障

 提供支持用户注销账号

 支持用户查询、更正或删除个人信息

 应及时反馈用户申诉