H5 应用安全风险分析与加固方案

H5应用安全风险分析与加固方案

目录

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.2客户端证书有效性校睑....................................................14

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

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

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

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

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

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

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

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

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

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

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

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

一.HTML5概述

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

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

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

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

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

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

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

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

二.HTML5应用开发模式

目前主流的应用程序大体分为三类：WebAPP、NativeAPP和Hybrid

APPo

•WebAPP：指采用H5语言写出的App,不需要下载安装。生存在浏览

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

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

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

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

上去类似NativeApp,但只有很少的UT组件，通过WebView组件加载

H5页面，展示Web内容。

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

特性WebAPPNativeAPPHybridAPP

开发语言

基于的操作系统

不同，实现的语展示界面通过115

使用Web开发语言不同，Java设计，交互通过

言即可和Object-C语Native语言实

言居现

多

代码移植和优化高无高

访问针对特定设低高中

备的特性

充分利用现有知高低高

识

高级图形中高中

低，需要通过应中，可局部更新

升级灵活性高

用商店或自检测和应用商店更新

下载升级包升级

安装体验中，通过移动浏高，从应用商店高，可从应用商

览器安装安装店安装

三.H5应用架构分析

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

客户端服务器端

客户端程序

H5页面脚本

DB

浏龙翔控件

（解析处理脚本）

用

户File

接

口

操作系统

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

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

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

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

•通用组件：操作系统

四.H5应用安全风险

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

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

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

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

移动应用攻击不包括WebAPP0

4.1H5应用面临的安全风险

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

•客户端安全

•通信安全

•服务器安全

■客户端程序保护安全•数据交互安全

•应用接口安全

•客户端•通信

•客户端运行^境安全•购安全认证

•客户端懒交互安全■雌

■运行环境安全

客户端安全通信安全服务端安全

4.2针对移动应用的攻击

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

种。

4.2.1静态攻击

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

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

选定安全防御脆

弱的目标

确定攻击点

开发攻击程序

反编译及逆向工找到应用漏洞

程分析

开发钓鱼程序

确定攻击方式

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

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

4.2.2动态攻击

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

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

所示：

|选定安全防御脆弱

I的目标

调试、注入应用

确定交易劫持点

确定用户信息劫持点

监测应用

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

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

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

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

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

4.3个人信息违规收集

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

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

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

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

4.4安全建设目标

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

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

下目标：

技术加固：

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

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

・强化授权认证的能力；

应用管理：

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

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

•建立持续的移列应用安全体系。

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

5.1SDK授权安全

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

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

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

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

后再传入服务器端。

•终端信息提取：提取终端信息，包括但不限于deviceid、mac地址、

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

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

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

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

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

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

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

防范。

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

对请求进行非法篡改。

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

露。

5.2客户端程序安全

5.2.1客户端程序保护

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

方案一方案二

•代码混淆对客户端程序进行加壳，提供

•具备运行时检查机制，防止抗逆向分析、代码保护、资源

攻击者对应用程序进行动态加密等保护。

调试

•具备签名验证机制

技术措施

•对于AndroidAPP的重要

操作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设备越狱状态检测

可通过判断设备中是否存在Cydia.app>MobileSubstrate.dylib^bash>

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

表所示：

/Applications/Cydia.app

/Library/MobileSubstrate/MobilcSubstrate.dylib

/bin/bash

/usr/sbin/sshd

/etc/apt

5.2.4数据存储安全

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

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

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

但不限于代码、内存、本地文件和本地数据库；

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

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

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

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

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

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

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

3）使用解密后亡勺加密密钥对数据解密。

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

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

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

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

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

应严格限制Activity、Service、BroadcastReceiver、Content

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

将exported属性设置为false。

5.2.5数据交互安全

敏感数据输入保护

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

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

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

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

如下要求：

1）键盘键位随机布局。

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

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

获取。

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

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

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

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

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

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

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

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

馈。

数据操作安全

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

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

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

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

类型数据的长度。

5.2.6资源管理

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

源泄漏。

5.3通信安全

5.3.1SSL/TLS安全配置

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

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

协议应满足如下要求：

（1）数字证书安全

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

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

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

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

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

替换旧私钥；

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

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

不能用于身份认证。

（2）协议安全

1）使用安全的协议，禁止使用SSLv2和v3,建议使用TLSvl.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

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

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

完整性。

5.4服务器端安全

5.4.1SDK授权

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

三方公司进行授权。

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

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

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

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

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

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

通信连接。

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

制：

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

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

权及签名相关私钥。

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

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

求的有效性。

5.4.2身份安全认证

会话安全

（1）Session安全管理

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

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

•用户登录时，应生成新的SessionID。

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

话。

（2）会话绑定

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

否变化做判断。

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

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

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

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

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

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

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

绑定设备指纹；

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

绑定设备指纹。

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

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

1）对于Android客户端应用，可通过设备中获取的deviceID^Pscudo-

L'niqueID＞mac地址、cpunumber＞系统版本等信息进行计算（hash处

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

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

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

器端用户会话进行绑定。

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

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

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

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

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

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

（3）防会话重放

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

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

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

I）序列号

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

算法（如序列号+1）;

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

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

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

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

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

2）时间戳

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

发送给服务器端。

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

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

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

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

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

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

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

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

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

战）。

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

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

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

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

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

（4）用户认证尝试超限锁定

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

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

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

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

射关系表进行俣存。

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

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

5.4.3短信验证码安全

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

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

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

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

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

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

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

（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数据交互安全

SQL注入攻击防护

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

语句，防范SQL注入攻击。

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

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

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

5.4.6.2跨站脚本攻击防护

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

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

不O

上下文场景编码处理

输出到HTML标签之间的数据调用EncodeXss.encodelltml方法对输出数据

做IIT

ML实体编码处理

输出到HTML标签的属性值的调用EncodeXss.encodeForlltmlAttr方法对

数输出数

据据进行转义处理

输出到JavaScript数据域中调用EncodeXss.encodeJS方法对输出数据

的数进行Jav

据aScript转义

输出到URL参数中的数据调用EncodeXss.encodeURL方法对输出数据

做UR

L编码处理

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

值中做编

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

输出到CSS样式表中的数据调用EncodeXss.encodeCSS方法对输出的数据

做转

义处理

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

输入为富文本内容的数据CleanRichHt

ml.cleanSafeHtml方法对输入的富文本内容

做过滤处

理

5.463上传文件安全

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

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

传恶意文件。

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

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

合法性进行基础校验。

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

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

件是否合法。

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

（2）文件安全存储

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

保存；

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

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

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

5.4.6.4防范路径遍历攻击

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

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

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

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

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

径建立映射关系；

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

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

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

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

（2）文件真实路径判断

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

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

5.4.6.5防范XML注入攻击

（1）防范XML数据注入

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

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

防范XML外部