為什么要安全

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

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

密鑰破解，導(dǎo)致本地加密數(shù)據(jù)被盜取

通信密鑰破解，導(dǎo)致接口數(shù)據(jù)被盜取

偽造接口數(shù)據(jù)上報(bào)

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

代碼反編譯

so破解

中間人攻擊用戶要的安全

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

本地加密

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

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

說完了這些代碼的安全，我們?cè)賮砜纯疵荑€的安全問題，前面說了，密鑰一定會(huì)『藏』在本地。

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

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

接口簽名

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

服務(wù)端要的安全

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

但客戶端在由不受信第三方(比如用戶)控制的情況下，基本不存在能夠驗(yàn)證請(qǐng)求是來自自己的”客戶端的方法，只能通過以下兩種方式來增加破解者的破解成本。

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

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

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

識(shí)別用戶請(qǐng)求鏈路

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

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

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

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

大數(shù)據(jù)識(shí)別，對(duì)識(shí)別為惡意請(qǐng)求的進(jìn)行封號(hào)處理這是目前比較主流的做法。

TCP加密

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

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

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

后現(xiàn)代安全

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

分享標(biāo)題：App開發(fā)安全設(shè)置二三事
文章路徑：http://www.rwnh.cn/news/64763.html

網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網(wǎng)站制作，網(wǎng)絡(luò)營銷seo公司；服務(wù)項(xiàng)目有網(wǎng)站制作、App開發(fā)等

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)