為什么要安全

　　現在幾乎所有App都是網(wǎng)絡(luò )強相關(guān)的，客戶(hù)端展示的很多東西都是通過(guò)接口從服務(wù)器上獲取的，當然，服務(wù)器也會(huì )接收大量從客戶(hù)端上傳的數據，這兩端在進(jìn)行雙向通信的時(shí)候，就很容易被第三方截獲，導致數據被盜取、接口被盜刷。

　　App的移動(dòng)安全主要包括下面幾種：

　　密鑰破解，導致本地加密數據被盜取

　　通信密鑰破解，導致接口數據被盜取

　　偽造接口數據上報

　　接口簽名被破解，導致接口可以被重放攻擊那么歸結起來(lái)，實(shí)際上就是這樣幾種模式：

　　代碼反編譯

　　so破解

　　中間人攻擊用戶(hù)要的安全

　　對于用戶(hù)來(lái)說(shuō)，他所需要的安全，是自己的敏感數據不被泄漏，不被第三方所知曉，所以，客戶(hù)端數據的安全，一般會(huì )使用加密的方式來(lái)保證安全，但數據既然存在本地，那么自然既需要加密，也需要解密(如果不需要解密，那么也就沒(méi)有保留的必要了)，所以，本地就一定會(huì )有加解密的密鑰，那么為了保證這個(gè)密鑰的安全，本地代碼又需要進(jìn)行加密，這樣突然好像就進(jìn)入了一個(gè)死循環(huán)，成了一個(gè)雞生蛋，蛋生雞的問(wèn)題，這也是為什么『本地沒(méi)有絕對的安全』這樣一說(shuō)的原因。

　　本地加密

　　本地的加密，我們通常從混淆——proguard入手，這是最簡(jiǎn)單的加密，成本最低，而且可以比較有效的扼殺一些在破解邊緣徘徊的初級破解者，讓他們能夠懸崖勒馬，浪子回頭，然而，對于真正想要破解的人來(lái)說(shuō)，混淆只等于加大了一點(diǎn)閱讀難度而已，相信做開(kāi)發(fā)的同學(xué)基本上也都反編譯過(guò)別人家的App，通過(guò)像jadx、apktool、dex2jar這樣的反編譯工具，可以非常方便的找到破解的蛛絲馬跡，特別像jadx這樣的反編譯神器，直接導出gradle工程去AS里面查看代碼，簡(jiǎn)直不要太舒服。
 

　　再高級一點(diǎn)，我們通過(guò)Dexguard、各種第三方so加固服務(wù)、加殼服務(wù)等方式來(lái)進(jìn)行保護，這些方式的確會(huì )極大的增加破解者的破解成本，到對于主流的加固技術(shù)，相應的破解技術(shù)也是非常成熟的，所以說(shuō)，雖然技術(shù)很牛逼，但只要破解者知道了你加固的方式，就可以輕而易舉的找到破解的方法，也就是比proguard多了一次Google的過(guò)程。

　　說(shuō)完了這些代碼的安全，我們再來(lái)看看密鑰的安全問(wèn)題，前面說(shuō)了，密鑰一定會(huì )『藏』在本地。

　　最低級的，密鑰被直接放在Java代碼中，這種基本上就是為了糊弄老板的，稍微高級點(diǎn)的，也放在Java代碼中，但是并不是直接讓你找到的，為了增加自己的一點(diǎn)信心，他會(huì )把密鑰拆成幾個(gè)部分，然后通過(guò)一定算法計算合成完整的密鑰，自欺欺人罷了，再高級一點(diǎn)，會(huì )把密鑰和加解密放so中，再進(jìn)一步，同樣將密鑰打散，通過(guò)一定算法進(jìn)行組裝，再高級一點(diǎn)，so再做下簽名校驗，加個(gè)花指令，甚至是一些人肉混淆(1、I、l)，一步步的，過(guò)濾了一批批小白、初級、中級、高級破解者，然而，天下無(wú)利不往，如果你的App真的有這樣的價(jià)值，那也一定會(huì )吸引那些骨灰破解者，畢竟人怕出名豬怕壯。

　　當然Google也總是后知后覺(jué)，在各種廠(chǎng)商提供了TrustZone/TEE硬件加密方案后，Google也推出了Keystore，當然，最低要API26才能使用，所以在現在來(lái)說(shuō)，幾乎不會(huì )有App能做到最低版本26，也就沒(méi)辦法借助Keystore來(lái)進(jìn)行安全存儲了。

　　接口簽名

　　接口上的安全，最基本的保證就是Https，同時(shí)對SSL協(xié)議的域名進(jìn)行校驗(關(guān)鍵詞：X509TrustManager、hostnameVerifier)，相信大部分的開(kāi)發(fā)者都沒(méi)有對這兩個(gè)地方進(jìn)行校驗，在此之上，請求的接口上，我們一般會(huì )帶上一個(gè)簽名，或者叫token，這個(gè)加密的密鑰串，就是我們身份的象征，一般來(lái)說(shuō)，這個(gè)簽名也就是通過(guò)前面我們千辛萬(wàn)苦要藏好的本地密鑰來(lái)進(jìn)行生成的，通常也就是那幾個(gè)參數，例如時(shí)間戳、UserID、IMEI、Mac地址等等進(jìn)行拼裝，然后通過(guò)DES、3DES、AES、hmacSHA1等方式進(jìn)行加密后，再經(jīng)過(guò)Base64進(jìn)行編碼生成的，這些加密過(guò)程就不贅述了，反正大家的都不一樣，根據關(guān)鍵詞大家去Google下就好了。

　　服務(wù)端要的安全

　　服務(wù)端需要的安全，主要是希望收到的請求，都真實(shí)的來(lái)自正常用戶(hù)的正常觸發(fā)。

　　但客戶(hù)端在由不受信第三方(比如用戶(hù))控制的情況下，基本不存在能夠驗證請求是來(lái)自“自己的”客戶(hù)端的方法，只能通過(guò)以下兩種方式來(lái)增加破解者的破解成本。

　　本地秘鑰+算法，用于生成接口簽名，難點(diǎn)在于如何保證本地秘鑰和算法的安全性，也就是我們前面說(shuō)的

　　動(dòng)態(tài)秘鑰，將密鑰的生成放在服務(wù)端，難點(diǎn)在于如何保證通信協(xié)議的安全性，同時(shí)也需要本地密鑰來(lái)保證請求動(dòng)態(tài)密鑰的接口安全動(dòng)態(tài)秘鑰下發(fā)的方案，需要在保證通信協(xié)議安全的情況下，才有實(shí)現價(jià)值，例如某活動(dòng)頁(yè)面的刷榜，可以增加一個(gè)前置依賴(lài)接口用于動(dòng)態(tài)返回秘鑰，客戶(hù)端使用該動(dòng)態(tài)秘鑰來(lái)進(jìn)行活動(dòng)頁(yè)面的請求，秘鑰不存本地，每次請求都是新的秘鑰，設置網(wǎng)絡(luò )請求框架的NO_PROXY模式，就是一個(gè)最簡(jiǎn)單的方案。

　　考慮到服務(wù)器設備的安全性，目前主流的防作弊檢測都是在服務(wù)端進(jìn)行，當然最主要的原因還是本地根本沒(méi)辦法保證絕對的安全。

　　識別用戶(hù)請求鏈路

　　根據必要的API調用流程和閉環(huán)，限制一組API調用中不同個(gè)體API相對于其它API的調用頻率(相對次數)限制。設定幾個(gè)隱秘的參數關(guān)聯(lián)邏輯，是跟業(yè)務(wù)邏輯環(huán)環(huán)相扣的，如果其他人想要自己拼裝參數，往往會(huì )打破這個(gè)隱秘約束。

　　但這個(gè)檢測通常需要耗費一定的系統資源，同時(shí)，當業(yè)務(wù)比較復雜的時(shí)候，如何保證請求檢測的實(shí)時(shí)性和高效性，就成了一個(gè)很難平衡的問(wèn)題。

　　網(wǎng)關(guān)層攔截、人機識別

　　網(wǎng)關(guān)層攔截同IP的大量重復請求，設置同IP訪(fǎng)問(wèn)的閾值。

　　大數據識別，對識別為惡意請求的進(jìn)行封號處理這是目前比較主流的做法。

　　TCP加密

　　目前大部分的App都是通過(guò)Http來(lái)進(jìn)行數據交互，但基于TCP，我們可以實(shí)現自己的通信協(xié)議，另外，利用TCP包的無(wú)序性來(lái)增加破解的難度，這樣，利用TCP心跳來(lái)維持一個(gè)安全的通信通道，也是一個(gè)非常不錯的方案，不過(guò)操作難度比較大。

　　修改業(yè)務(wù)邏輯處理方式

　　在設計業(yè)務(wù)技術(shù)實(shí)現方案時(shí)，將業(yè)務(wù)判斷邏輯放在后端，客戶(hù)端只做指令上發(fā)，判斷是否生效，在服務(wù)端進(jìn)行判斷。

　　后現代安全

　　量子加密、白盒加密、人工智能分析，這些基本都是下一代的安全策略，就當前來(lái)說(shuō)，還比較虛幻，不過(guò)只要技術(shù)一旦成熟，一定將是劃時(shí)代的里程碑。

　　?