移动应用App中间人攻击防御方法研究

吴学敏，颜 军，刘亚飞

（1.成都工业学院，四川 成都 610000；2.成都云盯科技有限公司，四川 成都 610000）

0 引 言

随着移动互联网技术的快速发展，移动应用市场规模的不断扩大，智能手机已成为人们生活工作必不可缺的产品，其出现和普及极大地促进了移动应用App的快速增长。根据工业和信息化部最新统计数据显示，截至2021年12月，我国国内市场上监测到的App数量为252万款，其中本土第三方应用商店App数量为117万款，苹果商店（中国区）App数量135万款[1]。5G网络时代的来临，也为App的持续发展和应用提供了坚实的基础。后疫情时代用户对移动应用App的依赖度持续增加，移动应用App的使用率在不断增加，人们在享受智能移动互联网时代移动应用App带来的便利的同时，也将面临诸多安全问题。

近年来，非法移动应用App的数量不断增加，类型也层出不穷，对移动应用的恶意攻击现象频发，特别是一些商业移动应用App已经成为黑产、灰产攻击的主要目标，安全形势愈发严峻。移动应用系统安全风险问题主要表现在以下3个方面。

（1）移动应用客户端。移动应用客户端可能滥用权限，违规收集和使用个人信息，导致用户的个人隐私泄露。具体表现在本地用户不知情或未经授权的情形下窃取用户的个人隐私，如非法打开用户的本地文件、蓝牙、网络、语音等操作；攻击者对移动应用App逆向分析，破解，再篡改或插入恶意代码，二次打包生成一个新应用程序，绕过用户的加密、认证中心，给用户使用带来安全风险，同时窃取开发人员核心代码算法，侵害开发人员及企业的权益；攻击者采用其他复杂的技术，对用户实施敲诈勒索等行为，非法获利。

（2）服务器。攻击者利用网络监听等手段盗取认证凭据，再重新发给服务器进行认证，对服务器实施重放攻击；SQL漏洞、XSS安全漏洞；服务器的密码和身份认证策略等。

（3）客户端与服务器通信。移动应用App客户端和服务器网络通信被非法拦截、篡改，遭遇中间人攻击[2]。

1 中间人攻击

1.1 中间人攻击概述

中间人攻击是指攻击者作为第三人的身份分别与需要建立通信关系的两端建立独立的联系，并非法获取双方的数据，作为通信两端的客户端和服务器都认为自己的连接对象是真实可靠的，但事实上整个会话都被攻击者完全控制，攻击者可以拦截通信双方的通话，获取敏感信息，甚至篡改部分内容。

1.2 中间人攻击分析

如图1所示，中间人发起攻击的流程如下：

图1 中间人攻击时序图

（1）客户端向服务器发起HTTPS请求；

（2）Charles（中间人）拦截客户端的请求，伪装成客户端向服务器进行请求；

（3）服务器向“客户端”返回服务器的CA证书，而“客户端”实际上是由Charles（中间人）伪装；

（4）Charles（中间人）拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端；

（5）客户端接收到“服务器”（实际上是中间人Charles）的证书后，生成一个对称密钥，用Charles（中间人）的公钥加密，发送给“服务器”（Charles）；

（6）Charles（中间人）拦截客户端的响应，用自己的私钥解密对称密钥（Charles拿到对称密钥），然后用服务器证书公钥加密，发送给服务器；

（7）服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应；

（8）Charles（中间人）拦截服务器的响应，替换成自己的证书后发送给客户端；

（9）至此，连接建立，Charles（中间人）获取了服务器证书的公钥和客户端与服务器协商的对称密钥，便就可以解密或者修改加密的报文了。

1.3 移动应用App中间人攻击测试

本文以Charles抓包工具为例模拟中间人攻击过程，测试模拟环境是一款商用移动应用App，该App需要购买会员才能获取如观看视频等权益。在该测试过程中，通过Charles工具抓包并修改服务器返回值中的有关字段即可实现非会员观看视频等权益。

如图2所示，Charles工具抓取的数据包为服务器对客服端的返回数据，当该数据中的 “subscribe”字段的值被篡改为1时，App客服端能够实现解锁用户权益。

图2 Charles抓包数据

从上述测试可知该移动应用App通信过程是基于明文传输，安全防护等级较低。

2 中间人攻击防御方法研究

2.1 SSL Pinning

SSL Pinning称为证书锁定（SSL/TLS Pinning），也称SSL证书绑定，实现的原理是将服务器提供的SSL/TLS证书提前内置到移动端开发的App中，当客户端发起网络请求获取数据时，会将内置在App中的SSL证书与服务器证书内容进行比对，判断是否一致，如果一致则当前连接合法[3]。SSL Pinning示意如图3所示。

图3 SSL Pinning示意图

为了防止中间人攻击，需要将App代码设置为只接收指定域名的证书，不接收系统或浏览器内置的CA根证书及其所对应的关联证书。通过这种授权方式，以确保App客户端与服务端通信的唯一性和安全性。CA签发证书都具有时效性，弊端是在证书续期后需要将证书重新内置到App中，所以要求采用该防御策略的App具备端上定期升级的能力。在实际操作中，可以在证书到期之后，通过App警告弹窗提示用户从指定的应用市场或官网下载最新版本继续使用。

2.2 数据加密算法

通过中间人攻击测试分析可知，如果服务器和客服端的通信数据采用密文传输，即使被非法拦截获取，也无法通过篡改对应字段来绕过App解锁获取权益。因此抵御中间人攻击的有效的方法为防范被直接获取明文，常用的加密方法如下文所述。

2.2.1 对称加密算法

对称加密算法采用单个密钥分别用于数据的加密与解密过程，优点是加密解密速度快、计算量小，因此适用于大量数据加密，其缺点是安全等级低。对称加密的安全性与加密算法本身没有多大关系，而取决于密钥，因而密钥会随着加密数据的增加而不断增加，会给密钥的分配和管理带来一定的负担。基于安全防护的考虑，故此次研究不会把对称加密应用于安全防护策略。

2.2.2 非对称加密算法

非对称和对称加密算法最大的区别是，其采用公钥和私钥两个不同的密钥进行加、解密，如发送方用公钥加密数据，接收方用私钥解密。常用的非对称算法RSA算法采取加密密钥和加密算法方法分开，为密钥的分配和管理提供了方便。

在使用非对称加密算法时，如公钥被中间人攻击获取，中间人将虚假信息用公钥加密，冒充发送者发送给接收方，接收方收到的假冒数据也能够用自己的私钥解密，但是却无法辨别发送者的真实身份，基于此可以采用数字签名的方式来解决。RSA算法是第一个既能用于加密和数字签名的非对称算法，是目前所公认的优秀的公钥方案之一[4]。

在实际的移动应用App开发中，通常直接把公钥放进代码里面，若系统被逆向，被中间人攻击者就能推出加密验签的原始内容及其关键字段，进而修改对应的业务字段，模拟计算出数字摘要，对App进行“欺骗”，绕过会员购买。为了避免这种情况，较为合理的方式是将公钥的载入用非字符串、用宏定义代替、或者调用函数规则运算生成密钥值，提高被逆向软件直接读取密钥的难度。

2.3 数字签名

数字签名是保护网络传输信息安全的重要方法之一，可以解决伪造、冒充、抵赖和篡改等问题。数字签名的实现过程是：（1）消息发送端将原始消息用哈希函数生成数字摘要；（2）用发送端的私钥对数字摘要进行加密，生成数字签名；（3）发送端将原始消息和数字签名一起发送给接收端；（4）接收端用公钥对数字签名进行解密还原成数字摘要，并且对原始消息用相同的哈希运算重新生成数字摘要；（5）比对还原后的数字摘要和新生成的数字摘要的一致性，如果一致则表明原始消息未被篡改。

使用数字签名可以确保接收到的某个信息确实是由相应的发送方所发送，避免了中间人等攻击者伪造、篡改、冒充消息等。由于私钥和公钥都是一一对应的，可以追溯到发送方的身份，数字签名也能确保发送方不可抵赖性。

3 方法实现及测试

3.1 方法实现

在本系统的工程应用中，采用了数字签名、SSL Pinning以及禁止App代理3种组合方式，从3个不同方面进行研究及工程应用。

3.1.1 数字签名的工程实现

在本文研究的移动应用App中，采用了哈希函数SHA256withRSA进行数字签名和验签。数字签名具体实现过程为先对原始消息（Raw Message）的进行哈希运算（SHA256withRSA）生成数字摘要，再用私钥（privateKey）对数字摘要加密生成数字签名（signedHash）。在iOS开发中，可以用系统自带的Security.framework的SecKeyRawSign函数实现数字签名，如图4所示。

图4 基于Security.framework实现数字签名

数字签名实现的核心方法可以简化为signedHash=SecKeyRawSign（privateKey,rawMessage）

数字签名验证的实现过程为首先对原始消息（Raw Message）的进行哈希运算（SHA256withRSA）生成新的数字摘要，其次用公钥（publicKey）对数字签名（signedHash）解密还原数字摘要，最后将解密和新生成的数字摘要进行比对。iOS 验签的核心代码可以简化为Status = SecKeyRawVerify（publicKey,originHash, signedHash）

同样可以使用iOS 系统自带的Security.framework中的SecKeyRawVerify方法实现验签，如图5所示。

图5 基于Security.framework实现验签

3.1.2 SSL Pinning的工程实现

在实际应用中，以iOS系统为例，开发者常常使用一款名为AFNetworking的网络请求库来请求网络数据，图6为该网络请求库的相关配置。实现过程是制作格式为.cer的SSL证书，在代码中读取该证书并赋值给AFSecurityPolicy。

图6 基于iOS的AFNetworking相关配置

3.1.3 禁用App代理

采用禁止App通过代理的方式来访问服务器，与服务器之间直接建立通信连接，以iOS为例，图7中“connectionProxyDictionary”字段属性可以用于设置网络代理，默认值是 NULL，表示允许代理。当该字段被设置为空字典(@{})时，则禁止代理，即可绕过中间人攻击的数据抓包。

图7 基于iOS的禁止APP代理配置代码

3.2 测试分析

3.2.1 SSL-Pinnig

如图8、图9所示，通过测试发现，使用SSL Pinning前，Charles可以正常抓包，使用SSL Pinning后无法抓包，该方法在一定程度上可以抵御中间人攻击。

图8 未开启SSL-Pinnig 可以正常抓取数据

图9 开启SSL-Pinnig 抓取数据失败

3.2.2 数字签名

如图10所示，验签通过后再做逻辑业务和权益的放行，杜绝了Charles断点修改服务端返回值绕过会员解锁逻辑或者市面上的代理工具定向修改返回值的操作，一定程度上保证了App的安全，提升了防篡改的能力。

图10 数字签名业务判断

4 结 论

本文分析了移动应用App在网络通信过程中存在 “中间人”攻击的安全风险，对防御“中间人”攻击的方法进行研究，并通过组合方式实现SSL Pinning、数字签名和禁止App代理上网的工程应用，避免了采用单一的安全防范措施而采用多重防御方法抵御中间人攻击，通过测试证明该防御策略符合实际应用场景，能够对商业App的经济权益起一定的保护作用。