web端安全
在過去的5年到10年之前，互聯(lián)網(wǎng)一直是web端天的天下，也就是我們常說的一個(gè)html頁(yè)面或者說是一個(gè)網(wǎng)站。那么我們今天就聊一聊從互聯(lián)網(wǎng)發(fā)展歷程至今安全架構(gòu)的演變。
在網(wǎng)頁(yè)橫行的天下里，相信之前做過網(wǎng)站，或者接觸過網(wǎng)站開發(fā)，或者了解http協(xié)議的都應(yīng)該聽說過一個(gè)詞,那就是session。
什么是session不是我們本文的重點(diǎn),我們這里要講述的是傳統(tǒng)的web網(wǎng)站架構(gòu)是怎么通過session來確保架構(gòu)安全性的?
那么歸結(jié)于實(shí)現(xiàn)的方式，傳統(tǒng)的網(wǎng)站基本都是如下的做法：
- 用戶帶著賬號(hào)和加密過后的密碼去登錄網(wǎng)站
- 服務(wù)器處理登錄請(qǐng)求
- 如果錯(cuò)誤,告知用戶
- 如果正確，吧userId放到對(duì)應(yīng)的session里
- 每次操作校驗(yàn)一下用戶session里的userId是否還在，session是否斷開
- 每次操作都是去session里取對(duì)應(yīng)的用戶信息，來判斷操作的用戶
APP架構(gòu)安全
auth協(xié)議
上面就是傳統(tǒng)web架構(gòu)下建立安全架構(gòu)的方式,但是時(shí)過境遷,我們又趕上了互聯(lián)網(wǎng)發(fā)展的大熱潮，這一次，我們是移動(dòng)客戶端的發(fā)展，也可以叫做移動(dòng)互聯(lián)網(wǎng)的浪潮。
那么這時(shí)候我們做過移動(dòng)端后臺(tái)開發(fā)的同學(xué)都會(huì)知道,我們是不會(huì)使用session的,也就是說我們的后臺(tái)是一個(gè)無session會(huì)話的server服務(wù)。那么這個(gè)時(shí)候我們的問題就來了，我們?cè)趺凑J(rèn)證對(duì)應(yīng)的每次請(qǐng)求是來自于哪一個(gè)用戶呢.
相信研究過session的朋友一定知道cookie的和session的關(guān)系,沒錯(cuò),就是每次請(qǐng)求,都是通過http請(qǐng)求中的cookie里的一個(gè)值來找到對(duì)應(yīng)的session的,這個(gè)cookie的值可以被我叫做服務(wù)器給客戶端頒發(fā)的令牌。
怎么去理解這個(gè)令牌呢，相當(dāng)于我有一個(gè)需要保密的大門,那么我為了保證不讓人隨便進(jìn)來,我給我的小弟們一個(gè)一個(gè)對(duì)應(yīng)的口令，如果這個(gè)人不在我手下了，那么我在我自己的認(rèn)證端吧他的口令刪除掉就好了。
相信大家已經(jīng)猜到我們要登場(chǎng)的角色了:沒錯(cuò)，上面就可以理解為一個(gè)簡(jiǎn)單版的基于token的auth授權(quán)協(xié)議.現(xiàn)在大多數(shù)的移動(dòng)服務(wù)端都是基于此種方式來構(gòu)建自己的安全架構(gòu)的.
https
在看完auth協(xié)議的實(shí)現(xiàn)架構(gòu)之后，有心的朋友應(yīng)該發(fā)現(xiàn)問題了，這丫的數(shù)據(jù)不是安全的啊。
問題出在哪里了呢，就是我在對(duì)你的網(wǎng)絡(luò)劫持了之后，我用抓包軟件去抓你的請(qǐng)求，就能拿到你的token，那么我就可以代替你的token來做請(qǐng)求了
臥槽，這么一聽好危險(xiǎn)，那么我們?cè)趺唇鉀Q這個(gè)問題？
非常簡(jiǎn)單。。。。把我們的服務(wù)器變成https的就好了，那么https是怎么上面的安全問題的呢？
讓我們先來了解一下https吧
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。 它是一個(gè)URI scheme（抽象標(biāo)識(shí)符體系），句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認(rèn)端口及一個(gè)加密/身份驗(yàn)證層（在HTTP與TCP之間）。
恩，我想大概你也懂了，其實(shí)https就是給我們所有的請(qǐng)求參數(shù)蒙上一層蒙娜麗莎的面具。
簽名驗(yàn)證
蒙娜麗莎的微笑是那么迷人，誰又能不陶醉呢？為了一觀那神秘的微笑，我用盡了全身的力氣。
好了不裝逼了，相信用過Charles的朋友，大概應(yīng)該都能知道，他有個(gè)功能是也能抓到https的請(qǐng)求包，那么我們https或許也不是那么安全了，媽個(gè)雞的，這可怎么辦，嚇?biāo)缹殞毩恕?/p>
還好本寶寶天資聰慧，想出了一個(gè)很好的解決辦法： 參數(shù)簽名。
那么什么是參數(shù)簽名呢？他又能做什么呢？
先說一下怎么去做這個(gè)參數(shù)簽名吧。
我舉個(gè)例子：
我有一個(gè)請(qǐng)求是這樣的https:aaa.com?a=1&b=2
那么相信你也看到了我請(qǐng)求中的參數(shù)是a=1&b=2,我這時(shí)候吧這兩個(gè)參數(shù)加上一個(gè)字符串我最帥，變成了這樣a=1&b=2我最帥,然后這個(gè)拼接好的字符串就行md5啊，或者sha1之類的單向加密,然后吧單向加密的結(jié)果做為一個(gè)參數(shù)sign=sdasfsdfw拼接到之前的請(qǐng)求里
然后我服務(wù)器在接受到請(qǐng)求的時(shí)候,吧除了sign之外的參數(shù)做和服務(wù)器一樣的操作，也就是生成簽名字符串，然后和傳過來的sign=sdasfsdfw簽名結(jié)果進(jìn)行對(duì)比，如果是相等的說明這個(gè)請(qǐng)求是正確的。
那么我簽名這個(gè)有啥用？這還要我說嗎？當(dāng)然是防止內(nèi)容篡改，防止偽造請(qǐng)求。
另外請(qǐng)注意一點(diǎn)：你一定要確保那個(gè)sign簽名時(shí)候的字符串的(例如之前的我最帥)不被他人知道,例如我們的安卓客戶端可以吧這個(gè)打到so庫(kù)里。
非對(duì)稱加密的藝術(shù)
我靠，這時(shí)候搞android逆向的朋友不服了,你丫就算給我打到so庫(kù)里，勞資照樣給你弄出來，一個(gè)小小的簽名就想難倒我？沒門。
我這時(shí)候呵呵一笑，出來混的，沒倆下子怎么好意思裝這個(gè)逼呢，對(duì)不對(duì)？
那么我這時(shí)候簽名都靠不住了，我咋辦，嗯哼，不知道朋友聽沒聽過非對(duì)稱加密。
yeah，我們這里就是要用這種技術(shù)，這里關(guān)于對(duì)稱和非對(duì)稱加密的相關(guān)知識(shí)不是本文的重點(diǎn)，故不再多提，感興趣的朋友可以自行谷歌。我們這里還是要說一下，怎么用這種加密方式提高安全性。
用過非對(duì)稱加密的朋友知道，這種方式有2個(gè)鑰匙，一個(gè)叫公共鑰匙，一個(gè)叫私有鑰匙，我們一般是吧公鑰暴漏在外，私鑰存在自己的包里。
在移動(dòng)端的架構(gòu)一般都是這樣的，生成公鑰和私鑰，吧公鑰放在客戶端存儲(chǔ)，或者客戶端去拉取。然后把私鑰放在基本處于安全狀態(tài)的服務(wù)器端（如果你說黑客能拿到這屬于服務(wù)器安全問題好伐），然后我們?cè)诿看握?qǐng)求的時(shí)候可以吧參數(shù)用公鑰加密，然后在服務(wù)器端解密，拿到真正的參數(shù)。
用了這種方式之后，保證你自己的代碼，你自己都不知道咋個(gè)搞丫，就算你丫牛逼到吧路由器劫持了，也休想知道我做了啥子撒，哈哈哈哈哈。
