首先插播一條本身的廣告——有些朋友可能都知道了，我最近建立了一個知識星球，在這裏試了一週，發現私密圈子的效率果真比羣要好不少，付費門檻過濾掉了大部分廣告和沒有意願學習分享的人，但願在這裏能彙集更多的熱愛學習熱愛分享的朋友，長按下面的二維碼來加入《程序員修仙指南》程序員

App安全二三事

客戶端防做弊，是一個很重要，但又很難作好的事情，矛與盾永遠是道高一尺，魔高一丈。算法

爲何要安全

如今幾乎全部App都是網絡強相關的，客戶端展現的不少東西都是經過接口從服務器上獲取的，固然，服務器也會接收大量從客戶端上傳的數據，這兩端在進行雙向通訊的時候，就很容易被第三方截獲，致使數據被盜取、接口被盜刷。後端

App的移動安全主要包括下面幾種：安全

密鑰破解，致使本地加密數據被盜取
通訊密鑰破解，致使接口數據被盜取
僞造接口數據上報
接口簽名被破解，致使接口能夠被重放攻擊

那麼歸結起來，實際上就是這樣幾種模式：服務器

代碼反編譯
so破解
中間人攻擊

用戶要的安全

對於用戶來講，他所須要的安全，是本身的敏感數據不被泄漏，不被第三方所知曉，因此，客戶端數據的安全，通常會使用加密的方式來保證安全，但數據既然存在本地，那麼天然既須要加密，也須要解密（若是不須要解密，那麼也就沒有保留的必要了），因此，本地就必定會有加解密的密鑰，那麼爲了保證這個密鑰的安全，本地代碼又須要進行加密，這樣忽然好像就進入了一個死循環，成了一個雞生蛋，蛋生雞的問題，這也是爲何『本地沒有絕對的安全』這樣一說的緣由。markdown

本地加密

本地的加密，咱們一般從混淆——proguard入手，這是最簡單的加密，成本最低，並且能夠比較有效的扼殺一些在破解邊緣徘徊的初級破解者，讓他們可以回頭是岸，浪子回頭，然而，對於真正想要破解的人來講，混淆只等於加大了一點閱讀難度而已，相信作開發的同窗基本上也都反編譯過別人家的App，經過像jadx、apktool、dex2jar這樣的反編譯工具，能夠很是方便的找到破解的蛛絲馬跡，特別像jadx這樣的反編譯神器，直接導出gradle工程去AS裏面查看代碼，簡直不要太舒服。網絡

再高級一點，咱們經過Dexguard、各類第三方so加固服務、加殼服務等方式來進行保護，這些方式的確會極大的增長破解者的破解成本，到對於主流的加固技術，相應的破解技術也是很是成熟的，因此說，雖然技術很牛逼，但只要破解者知道了你加固的方式，就能夠垂手可得的找到破解的方法，也就是比proguard多了一次Google的過程。框架

說完了這些代碼的安全，咱們再來看看密鑰的安全問題，前面說了，密鑰必定會『藏』在本地。工具

最低級的，密鑰被直接放在Java代碼中，這種基本上就是爲了糊弄老闆的，稍微高級點的，也放在Java代碼中，可是並非直接讓你找到的，爲了增長本身的一點信心，他會把密鑰拆成幾個部分，而後經過必定算法計算合成完整的密鑰，自欺欺人罷了，再高級一點，會把密鑰和加解密放so中，再進一步，一樣將密鑰打散，經過必定算法進行組裝，再高級一點，so再作下簽名校驗，加個花指令，甚至是一些人肉混淆（一、I、l），一步步的，過濾了一批批小白、初級、中級、高級破解者，然而，天下無利不往，若是你的App真的有這樣的價值，那也必定會吸引那些骨灰破解者，畢竟人怕出名豬怕壯。學習

固然Google也老是後知後覺，在各類廠商提供了TrustZone/TEE硬件加密方案後，Google也推出了Keystore，固然，最低要API26才能使用，因此在如今來講，幾乎不會有App能作到最低版本26，也就沒辦法藉助Keystore來進行安全存儲了。

接口簽名

接口上的安全，最基本的保證就是Https，同時對SSL協議的域名進行校驗（關鍵詞：X509TrustManager、hostnameVerifier），相信大部分的開發者都沒有對這兩個地方進行校驗，在此之上，請求的接口上，咱們通常會帶上一個簽名，或者叫token，這個加密的密鑰串，就是咱們身份的象徵，通常來講，這個簽名也就是經過前面咱們千辛萬苦要藏好的本地密鑰來進行生成的，一般也就是那幾個參數，例如時間戳、UserID、IMEI、Mac地址等等進行拼裝，而後經過DES、3DES、AES、hmacSHA1等方式進行加密後，再通過Base64進行編碼生成的，這些加密過程就不贅述了，反正你們的都不同，根據關鍵詞你們去Google下就行了。

服務端要的安全

服務端須要的安全，主要是但願收到的請求，都真實的來自正經常使用戶的正常觸發。

但客戶端在由不受信第三方（好比用戶）控制的狀況下，基本不存在可以驗證請求是來自「本身的」客戶端的方法，只能經過如下兩種方式來增長破解者的破解成本。

本地祕鑰+算法，用於生成接口簽名，難點在於如何保證本地祕鑰和算法的安全性，也就是咱們前面說的
動態祕鑰，將密鑰的生成放在服務端，難點在於如何保證通訊協議的安全性，同時也須要本地密鑰來保證請求動態密鑰的接口安全

動態祕鑰下發的方案，須要在保證通訊協議安全的狀況下，纔有實現價值，例如某活動頁面的刷榜，能夠增長一個前置依賴接口用於動態返回祕鑰，客戶端使用該動態祕鑰來進行活動頁面的請求，祕鑰不存本地，每次請求都是新的祕鑰，設置網絡請求框架的NO_PROXY模式，就是一個最簡單的方案。

考慮到服務器設備的安全性，目前主流的防做弊檢測都是在服務端進行，固然最主要的緣由仍是本地根本沒辦法保證絕對的安全。

識別用戶請求鏈路

根據必要的API調用流程和閉環，限制一組API調用中不一樣個體API相對於其它API的調用頻率（相對次數）限制。設定幾個隱祕的參數關聯邏輯，是跟業務邏輯環環相扣的，若是其餘人想要本身拼裝參數，每每會打破這個隱祕約束。

但這個檢測一般須要耗費必定的系統資源，同時，當業務比較複雜的時候，如何保證請求檢測的實時性和高效性，就成了一個很難平衡的問題。

網關層攔截、人機識別

網關層攔截同IP的大量重複請求，設置同IP訪問的閾值。
大數據識別，對識別爲惡意請求的進行封號處理

這是目前比較主流的作法。

TCP加密

目前大部分的App都是經過Http來進行數據交互，但基於TCP，咱們能夠實現本身的通訊協議，另外，利用TCP包的無序性來增長破解的難度，這樣，利用TCP心跳來維持一個安全的通訊通道，也是一個很是不錯的方案，不過操做難度比較大。

修改業務邏輯處理方式

在設計業務技術實現方案時，將業務判斷邏輯放在後端，客戶端只作指令上發，判斷是否生效，在服務端進行判斷。

後現代安全

量子加密、白盒加密、人工智能分析，這些基本都是下一代的安全策略，就當前來講，還比較虛幻，不過只要技術一旦成熟，必定將是劃時代的里程碑。

另外，知識星球是能夠經過分享來獲取獎勵的，在『程序員修仙智能』中，點擊左上角能夠進行分享界面，選擇分享星球便可拿到本身的獎勵。