吳學(xué)敏，顏 軍，劉亞飛

（1.成都工業(yè)學(xué)院，四川 成都 610000；2.成都云盯科技有限公司，四川 成都 610000）

0 引 言

隨著移動互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，移動應(yīng)用市場規(guī)模的不斷擴(kuò)大，智能手機(jī)已成為人們生活工作必不可缺的產(chǎn)品，其出現(xiàn)和普及極大地促進(jìn)了移動應(yīng)用App的快速增長。根據(jù)工業(yè)和信息化部最新統(tǒng)計數(shù)據(jù)顯示，截至2021年12月，我國國內(nèi)市場上監(jiān)測到的App數(shù)量為252萬款，其中本土第三方應(yīng)用商店App數(shù)量為117萬款，蘋果商店（中國區(qū)）App數(shù)量135萬款[1]。5G網(wǎng)絡(luò)時代的來臨，也為App的持續(xù)發(fā)展和應(yīng)用提供了堅實的基礎(chǔ)。后疫情時代用戶對移動應(yīng)用App的依賴度持續(xù)增加，移動應(yīng)用App的使用率在不斷增加，人們在享受智能移動互聯(lián)網(wǎng)時代移動應(yīng)用App帶來的便利的同時，也將面臨諸多安全問題。

近年來，非法移動應(yīng)用App的數(shù)量不斷增加，類型也層出不窮，對移動應(yīng)用的惡意攻擊現(xiàn)象頻發(fā)，特別是一些商業(yè)移動應(yīng)用App已經(jīng)成為黑產(chǎn)、灰產(chǎn)攻擊的主要目標(biāo)，安全形勢愈發(fā)嚴(yán)峻。移動應(yīng)用系統(tǒng)安全風(fēng)險問題主要表現(xiàn)在以下3個方面。

（1）移動應(yīng)用客戶端。移動應(yīng)用客戶端可能濫用權(quán)限，違規(guī)收集和使用個人信息，導(dǎo)致用戶的個人隱私泄露。具體表現(xiàn)在本地用戶不知情或未經(jīng)授權(quán)的情形下竊取用戶的個人隱私，如非法打開用戶的本地文件、藍(lán)牙、網(wǎng)絡(luò)、語音等操作；攻擊者對移動應(yīng)用App逆向分析，破解，再篡改或插入惡意代碼，二次打包生成一個新應(yīng)用程序，繞過用戶的加密、認(rèn)證中心，給用戶使用帶來安全風(fēng)險，同時竊取開發(fā)人員核心代碼算法，侵害開發(fā)人員及企業(yè)的權(quán)益；攻擊者采用其他復(fù)雜的技術(shù)，對用戶實施敲詐勒索等行為，非法獲利。

（2）服務(wù)器。攻擊者利用網(wǎng)絡(luò)監(jiān)聽等手段盜取認(rèn)證憑據(jù)，再重新發(fā)給服務(wù)器進(jìn)行認(rèn)證，對服務(wù)器實施重放攻擊；SQL漏洞、XSS安全漏洞；服務(wù)器的密碼和身份認(rèn)證策略等。

（3）客戶端與服務(wù)器通信。移動應(yīng)用App客戶端和服務(wù)器網(wǎng)絡(luò)通信被非法攔截、篡改，遭遇中間人攻擊[2]。

1 中間人攻擊

1.1 中間人攻擊概述

中間人攻擊是指攻擊者作為第三人的身份分別與需要建立通信關(guān)系的兩端建立獨(dú)立的聯(lián)系，并非法獲取雙方的數(shù)據(jù)，作為通信兩端的客戶端和服務(wù)器都認(rèn)為自己的連接對象是真實可靠的，但事實上整個會話都被攻擊者完全控制，攻擊者可以攔截通信雙方的通話，獲取敏感信息，甚至篡改部分內(nèi)容。

1.2 中間人攻擊分析

如圖1所示，中間人發(fā)起攻擊的流程如下：

圖1 中間人攻擊時序圖

（1）客戶端向服務(wù)器發(fā)起HTTPS請求；

（2）Charles（中間人）攔截客戶端的請求，偽裝成客戶端向服務(wù)器進(jìn)行請求；

（3）服務(wù)器向“客戶端”返回服務(wù)器的CA證書，而“客戶端”實際上是由Charles（中間人）偽裝；

（4）Charles（中間人）攔截服務(wù)器的響應(yīng)，獲取服務(wù)器證書公鑰，然后自己制作一張證書，將服務(wù)器證書替換后發(fā)送給客戶端；

（5）客戶端接收到“服務(wù)器”（實際上是中間人Charles）的證書后，生成一個對稱密鑰，用Charles（中間人）的公鑰加密，發(fā)送給“服務(wù)器”（Charles）；

（6）Charles（中間人）攔截客戶端的響應(yīng)，用自己的私鑰解密對稱密鑰（Charles拿到對稱密鑰），然后用服務(wù)器證書公鑰加密，發(fā)送給服務(wù)器；

（7）服務(wù)器用自己的私鑰解密對稱密鑰，向“客戶端”（Charles）發(fā)送響應(yīng)；

（8）Charles（中間人）攔截服務(wù)器的響應(yīng)，替換成自己的證書后發(fā)送給客戶端；

（9）至此，連接建立，Charles（中間人）獲取了服務(wù)器證書的公鑰和客戶端與服務(wù)器協(xié)商的對稱密鑰，便就可以解密或者修改加密的報文了。

1.3 移動應(yīng)用App中間人攻擊測試

本文以Charles抓包工具為例模擬中間人攻擊過程，測試模擬環(huán)境是一款商用移動應(yīng)用App，該App需要購買會員才能獲取如觀看視頻等權(quán)益。在該測試過程中，通過Charles工具抓包并修改服務(wù)器返回值中的有關(guān)字段即可實現(xiàn)非會員觀看視頻等權(quán)益。

如圖2所示，Charles工具抓取的數(shù)據(jù)包為服務(wù)器對客服端的返回數(shù)據(jù)，當(dāng)該數(shù)據(jù)中的 “subscribe”字段的值被篡改為1時，App客服端能夠?qū)崿F(xiàn)解鎖用戶權(quán)益。

圖2 Charles抓包數(shù)據(jù)

從上述測試可知該移動應(yīng)用App通信過程是基于明文傳輸，安全防護(hù)等級較低。

2 中間人攻擊防御方法研究

2.1 SSL Pinning

SSL Pinning稱為證書鎖定（SSL/TLS Pinning），也稱SSL證書綁定，實現(xiàn)的原理是將服務(wù)器提供的SSL/TLS證書提前內(nèi)置到移動端開發(fā)的App中，當(dāng)客戶端發(fā)起網(wǎng)絡(luò)請求獲取數(shù)據(jù)時，會將內(nèi)置在App中的SSL證書與服務(wù)器證書內(nèi)容進(jìn)行比對，判斷是否一致，如果一致則當(dāng)前連接合法[3]。SSL Pinning示意如圖3所示。

圖3 SSL Pinning示意圖

為了防止中間人攻擊，需要將App代碼設(shè)置為只接收指定域名的證書，不接收系統(tǒng)或瀏覽器內(nèi)置的CA根證書及其所對應(yīng)的關(guān)聯(lián)證書。通過這種授權(quán)方式，以確保App客戶端與服務(wù)端通信的唯一性和安全性。CA簽發(fā)證書都具有時效性，弊端是在證書續(xù)期后需要將證書重新內(nèi)置到App中，所以要求采用該防御策略的App具備端上定期升級的能力。在實際操作中，可以在證書到期之后，通過App警告彈窗提示用戶從指定的應(yīng)用市場或官網(wǎng)下載最新版本繼續(xù)使用。

2.2 數(shù)據(jù)加密算法

通過中間人攻擊測試分析可知，如果服務(wù)器和客服端的通信數(shù)據(jù)采用密文傳輸，即使被非法攔截獲取，也無法通過篡改對應(yīng)字段來繞過App解鎖獲取權(quán)益。因此抵御中間人攻擊的有效的方法為防范被直接獲取明文，常用的加密方法如下文所述。

2.2.1 對稱加密算法

對稱加密算法采用單個密鑰分別用于數(shù)據(jù)的加密與解密過程，優(yōu)點是加密解密速度快、計算量小，因此適用于大量數(shù)據(jù)加密，其缺點是安全等級低。對稱加密的安全性與加密算法本身沒有多大關(guān)系，而取決于密鑰，因而密鑰會隨著加密數(shù)據(jù)的增加而不斷增加，會給密鑰的分配和管理帶來一定的負(fù)擔(dān)?；诎踩雷o(hù)的考慮，故此次研究不會把對稱加密應(yīng)用于安全防護(hù)策略。

2.2.2 非對稱加密算法

非對稱和對稱加密算法最大的區(qū)別是，其采用公鑰和私鑰兩個不同的密鑰進(jìn)行加、解密，如發(fā)送方用公鑰加密數(shù)據(jù)，接收方用私鑰解密。常用的非對稱算法RSA算法采取加密密鑰和加密算法方法分開，為密鑰的分配和管理提供了方便。

在使用非對稱加密算法時，如公鑰被中間人攻擊獲取，中間人將虛假信息用公鑰加密，冒充發(fā)送者發(fā)送給接收方，接收方收到的假冒數(shù)據(jù)也能夠用自己的私鑰解密，但是卻無法辨別發(fā)送者的真實身份，基于此可以采用數(shù)字簽名的方式來解決。RSA算法是第一個既能用于加密和數(shù)字簽名的非對稱算法，是目前所公認(rèn)的優(yōu)秀的公鑰方案之一[4]。

在實際的移動應(yīng)用App開發(fā)中，通常直接把公鑰放進(jìn)代碼里面，若系統(tǒng)被逆向，被中間人攻擊者就能推出加密驗簽的原始內(nèi)容及其關(guān)鍵字段，進(jìn)而修改對應(yīng)的業(yè)務(wù)字段，模擬計算出數(shù)字摘要，對App進(jìn)行“欺騙”，繞過會員購買。為了避免這種情況，較為合理的方式是將公鑰的載入用非字符串、用宏定義代替、或者調(diào)用函數(shù)規(guī)則運(yùn)算生成密鑰值，提高被逆向軟件直接讀取密鑰的難度。

2.3 數(shù)字簽名

數(shù)字簽名是保護(hù)網(wǎng)絡(luò)傳輸信息安全的重要方法之一，可以解決偽造、冒充、抵賴和篡改等問題。數(shù)字簽名的實現(xiàn)過程是：（1）消息發(fā)送端將原始消息用哈希函數(shù)生成數(shù)字摘要；（2）用發(fā)送端的私鑰對數(shù)字摘要進(jìn)行加密，生成數(shù)字簽名；（3）發(fā)送端將原始消息和數(shù)字簽名一起發(fā)送給接收端；（4）接收端用公鑰對數(shù)字簽名進(jìn)行解密還原成數(shù)字摘要，并且對原始消息用相同的哈希運(yùn)算重新生成數(shù)字摘要；（5）比對還原后的數(shù)字摘要和新生成的數(shù)字摘要的一致性，如果一致則表明原始消息未被篡改。

使用數(shù)字簽名可以確保接收到的某個信息確實是由相應(yīng)的發(fā)送方所發(fā)送，避免了中間人等攻擊者偽造、篡改、冒充消息等。由于私鑰和公鑰都是一一對應(yīng)的，可以追溯到發(fā)送方的身份，數(shù)字簽名也能確保發(fā)送方不可抵賴性。

3 方法實現(xiàn)及測試

3.1 方法實現(xiàn)

在本系統(tǒng)的工程應(yīng)用中，采用了數(shù)字簽名、SSL Pinning以及禁止App代理3種組合方式，從3個不同方面進(jìn)行研究及工程應(yīng)用。

3.1.1 數(shù)字簽名的工程實現(xiàn)

在本文研究的移動應(yīng)用App中，采用了哈希函數(shù)SHA256withRSA進(jìn)行數(shù)字簽名和驗簽。數(shù)字簽名具體實現(xiàn)過程為先對原始消息（Raw Message）的進(jìn)行哈希運(yùn)算（SHA256withRSA）生成數(shù)字摘要，再用私鑰（privateKey）對數(shù)字摘要加密生成數(shù)字簽名（signedHash）。在iOS開發(fā)中，可以用系統(tǒng)自帶的Security.framework的SecKeyRawSign函數(shù)實現(xiàn)數(shù)字簽名，如圖4所示。

圖4 基于Security.framework實現(xiàn)數(shù)字簽名

數(shù)字簽名實現(xiàn)的核心方法可以簡化為signedHash=SecKeyRawSign（privateKey,rawMessage）

數(shù)字簽名驗證的實現(xiàn)過程為首先對原始消息（Raw Message）的進(jìn)行哈希運(yùn)算（SHA256withRSA）生成新的數(shù)字摘要，其次用公鑰（publicKey）對數(shù)字簽名（signedHash）解密還原數(shù)字摘要，最后將解密和新生成的數(shù)字摘要進(jìn)行比對。iOS 驗簽的核心代碼可以簡化為Status = SecKeyRawVerify（publicKey,originHash, signedHash）

同樣可以使用iOS 系統(tǒng)自帶的Security.framework中的SecKeyRawVerify方法實現(xiàn)驗簽，如圖5所示。

圖5 基于Security.framework實現(xiàn)驗簽

3.1.2 SSL Pinning的工程實現(xiàn)

在實際應(yīng)用中，以iOS系統(tǒng)為例，開發(fā)者常常使用一款名為AFNetworking的網(wǎng)絡(luò)請求庫來請求網(wǎng)絡(luò)數(shù)據(jù)，圖6為該網(wǎng)絡(luò)請求庫的相關(guān)配置。實現(xiàn)過程是制作格式為.cer的SSL證書，在代碼中讀取該證書并賦值給AFSecurityPolicy。

圖6 基于iOS的AFNetworking相關(guān)配置

3.1.3 禁用App代理

采用禁止App通過代理的方式來訪問服務(wù)器，與服務(wù)器之間直接建立通信連接，以iOS為例，圖7中“connectionProxyDictionary”字段屬性可以用于設(shè)置網(wǎng)絡(luò)代理，默認(rèn)值是 NULL，表示允許代理。當(dāng)該字段被設(shè)置為空字典(@{})時，則禁止代理，即可繞過中間人攻擊的數(shù)據(jù)抓包。

圖7 基于iOS的禁止APP代理配置代碼

3.2 測試分析

3.2.1 SSL-Pinnig

如圖8、圖9所示，通過測試發(fā)現(xiàn)，使用SSL Pinning前，Charles可以正常抓包，使用SSL Pinning后無法抓包，該方法在一定程度上可以抵御中間人攻擊。

圖8 未開啟SSL-Pinnig 可以正常抓取數(shù)據(jù)

圖9 開啟SSL-Pinnig 抓取數(shù)據(jù)失敗

3.2.2 數(shù)字簽名

如圖10所示，驗簽通過后再做邏輯業(yè)務(wù)和權(quán)益的放行，杜絕了Charles斷點修改服務(wù)端返回值繞過會員解鎖邏輯或者市面上的代理工具定向修改返回值的操作，一定程度上保證了App的安全，提升了防篡改的能力。

圖10 數(shù)字簽名業(yè)務(wù)判斷

4 結(jié) 論

本文分析了移動應(yīng)用App在網(wǎng)絡(luò)通信過程中存在 “中間人”攻擊的安全風(fēng)險，對防御“中間人”攻擊的方法進(jìn)行研究，并通過組合方式實現(xiàn)SSL Pinning、數(shù)字簽名和禁止App代理上網(wǎng)的工程應(yīng)用，避免了采用單一的安全防范措施而采用多重防御方法抵御中間人攻擊，通過測試證明該防御策略符合實際應(yīng)用場景，能夠?qū)ι虡I(yè)App的經(jīng)濟(jì)權(quán)益起一定的保護(hù)作用。