見過一些系統(tǒng)和應(yīng)用在裸奔，也見過一些簡單的應(yīng)用設(shè)計了極其復(fù)雜的安全機(jī)制，不僅團(tuán)隊成員很難掌握，而且還影響到業(yè)務(wù)開發(fā)。所以我經(jīng)常會想，什么樣的網(wǎng)絡(luò)請求才是合理的？

• 一個APP或者網(wǎng)站，怎么區(qū)分當(dāng)前用戶是誰呢？我可以在請求參數(shù)里附帶UserID，通過UserID我可以知道返回什么樣的數(shù)據(jù)或者展示什么樣的內(nèi)容。這時只要我在請求時修改一下UserID，就能看到其他用戶的信息了，別笑，這樣的系統(tǒng)確實(shí)存在，只在登錄時確認(rèn)了下UserID。

網(wǎng)絡(luò)請求時序圖 .png

• 當(dāng)然能犯這么低級錯誤的比較是少數(shù)，為了防止這種情況，有些系統(tǒng)每次請求都附帶了用戶名和密碼(加密后的也可以直接使用)，這樣你不知道別人密碼 ，很難冒充別人請求了，但是這種設(shè)計依然很差勁，即使你的用戶名和密碼是加密的，每天這么傳來傳去也不合適，傳輸過程中隨便有人抓個包，拿到你的用戶名和密碼，就可以冒用你身份了，關(guān)鍵還要把用戶名這么重要的東西存儲的客戶端。

網(wǎng)絡(luò)請求時序圖.png

• 于是有人更進(jìn)一步，通過登錄請求返回一個token，這個token有一個有效期，這樣后面所有請求都通過傳遞token標(biāo)識用戶身份。雖然登錄請求時依然要傳遞用戶名密碼，但是大部分情況下只需要傳遞token還是安全很多的，畢竟可以有很多token失效策略用來提高安全性。當(dāng)然token可以像上面改UserID一樣被暴力試出來，尤其是量級很大的應(yīng)用，所以UserID+token比單純token被試出概率低很多。目前很多應(yīng)用都是采用這種方式，雖說可以被抓包，畢竟這個門檻還是很高的，當(dāng)然前提是你不要輕易連接未知WIFI。

網(wǎng)絡(luò)請求時序圖 (3).png

• 怎么可以不怕被抓包呢？有一個簡單的方法就是給請求加一個驗(yàn)簽，簡單說就是每個請求都加一個簽名用來證明是你發(fā)出的請求，而不是惡意第三方。最常見的一個方法就是根據(jù)請求的參數(shù)生成一個簽名附帶到請求中，那么即使有人抓包拿到了你的請求，他也很難冒充你去發(fā)請求，因?yàn)樗恢篮灻刹呗裕鴶r截到的簽名，通常也都跟時間戳相關(guān)，所以也很難再繼續(xù)使用。例如下面的截圖，是嗶哩嗶哩APP的請求，如果你覺得現(xiàn)在你就可以自己直接發(fā)請求去拉他們數(shù)據(jù)，那只能說你圖樣圖森破，仔細(xì)看一下它的url:http://api.live.bilibili.com/AppNewIndex/common?_device=android&appkey=1d8b6e7d45233436&build=505000&mobi_app=android&platform=android&scale=xxhdpi&ts=1495789431&sign=cb2bd248088aee941a0a8f5d75fbb091 看到后面那個sign=xxxx了么？這個就是延簽，你不知道它的生成算法，你的所以請求它都不鳥你的。當(dāng)然也可以把所有數(shù)據(jù)都加密，抓包抓到的就是一堆亂碼。目前主流的網(wǎng)絡(luò)請求基本都是采用這種策略。攻擊者可以通過分析前端代碼或者分析反編譯后的客戶端代碼，獲取加密或者生成驗(yàn)簽的算法來破解這種安全方案。

image.png

• 還有一種方法，就是使用https，它能保證數(shù)據(jù)傳輸過程中實(shí)安全的。盡管有中間者攻擊，但是只要客戶端驗(yàn)證服務(wù)器證書，就可以很容易識破攻擊者。瀏覽器默認(rèn)可以驗(yàn)證CA簽署的證書的，自簽名或者攻擊者的簽名，瀏覽器會有安全警告。手機(jī)APP的話需要自己實(shí)現(xiàn)證書驗(yàn)證步驟。各方面來講，https還是很安全的，目前各個大廠都在推https，如果說缺點(diǎn)的話，那就是可以通過抓包工具分析請求，上面說了可以防止中間者攻擊，但是用戶安裝中間者證書并且信任它那就沒辦法了，并且通常場景https都是單向驗(yàn)證，那么如果接口設(shè)計不合理，攻擊者就可以通過直接發(fā)送請求完成攻擊。

網(wǎng)絡(luò)請求時序圖 (6).png

• 根據(jù)上面分析，可以把5和4組合使用，達(dá)到類似于雙向驗(yàn)證的效果來提高安全性。那么這種方案唯一的攻擊入口就在于破解4中提到的加密算法。
• 前端代碼通過混淆實(shí)現(xiàn)算法保護(hù)，android也是通過混淆對java代碼進(jìn)行保護(hù)，不過它的反射機(jī)制暴露了每一個Activity，給破解者提供了一個很好的切入點(diǎn)，所以為了提高安全性，很多Android開發(fā)者都把一些核心算法的實(shí)現(xiàn)放到lib.so中實(shí)現(xiàn)。放lib.so中就很安全嗎？答案肯定是否定的，但是它把破解難度提高了很多，它是ELF文件格式，通過工具可以拿到匯編代碼，尤其android中native方法名不能混淆，也暴露了默認(rèn)C/C++實(shí)現(xiàn)的函數(shù)名。不少Android應(yīng)用僅僅通過lib.so獲取字符串方式隱藏加密密鑰或者特殊code，這種方式破解難度就更低了，找到特殊關(guān)鍵字直接從匯編代碼中搜索，更有甚者破解者直接寫代碼調(diào)用你的lib.so獲取結(jié)果，可以看下面的截圖，是默認(rèn)JNI的例子生成的so反編譯后的結(jié)果。為了再次提高安全等級，就出現(xiàn)了加殼技術(shù)。IOS程序就是加殼后的ELF文件，如上分析Android做了這么多工作才達(dá)到了IOS的安全程度，這也是為啥大家都說IOS難破解，當(dāng)然加殼后也不是絕對安全，大家應(yīng)該經(jīng)常聽到脫殼技術(shù)。梆梆和360都推出了針對Android的加固服務(wù)，但是很快就被安全愛好者脫殼并公布方法(當(dāng)然它們肯定會推出新的加固方案)，所以安全沒有絕對的，就看你要做到什么地步了。下一篇我會按照上述思路實(shí)現(xiàn)一套網(wǎng)絡(luò)數(shù)據(jù)安全方案。

image.png

image.png