web端安全
在過去的5年到10年之前，互聯(lián)網(wǎng)一直是web端天的天下，也就是我們常說的一個html頁面或者說是一個網(wǎng)站院仿。那么我們今天就聊一聊從互聯(lián)網(wǎng)發(fā)展歷程至今安全架構(gòu)的演變。
在網(wǎng)頁橫行的天下里勺届，相信之前做過網(wǎng)站驶俊，或者接觸過網(wǎng)站開發(fā)娶耍，或者了解http協(xié)議的都應(yīng)該聽說過一個詞,那就是session。
什么是session不是我們本文的重點,我們這里要講述的是傳統(tǒng)的web網(wǎng)站架構(gòu)是怎么通過session來確保架構(gòu)安全性的?
那么歸結(jié)于實現(xiàn)的方式饼酿，傳統(tǒng)的網(wǎng)站基本都是如下的做法：
- 用戶帶著賬號和加密過后的密碼去登錄網(wǎng)站
- 服務(wù)器處理登錄請求
- 如果錯誤,告知用戶
- 如果正確榕酒，吧userId放到對應(yīng)的session里
- 每次操作校驗一下用戶session里的userId是否還在，session是否斷開
- 每次操作都是去session里取對應(yīng)的用戶信息故俐，來判斷操作的用戶
APP架構(gòu)安全
auth協(xié)議
上面就是傳統(tǒng)web架構(gòu)下建立安全架構(gòu)的方式,但是時過境遷,我們又趕上了互聯(lián)網(wǎng)發(fā)展的大熱潮想鹰，這一次，我們是移動客戶端的發(fā)展药版，也可以叫做移動互聯(lián)網(wǎng)的浪潮辑舷。
那么這時候我們做過移動端后臺開發(fā)的同學(xué)都會知道,我們是不會使用session的,也就是說我們的后臺是一個無session會話的server服務(wù)。那么這個時候我們的問題就來了槽片，我們怎么認證對應(yīng)的每次請求是來自于哪一個用戶呢.
相信研究過session的朋友一定知道cookie的和session的關(guān)系,沒錯,就是每次請求,都是通過http請求中的cookie里的一個值來找到對應(yīng)的session的,這個cookie的值可以被我叫做服務(wù)器給客戶端頒發(fā)的令牌何缓。
怎么去理解這個令牌呢，相當于我有一個需要保密的大門,那么我為了保證不讓人隨便進來,我給我的小弟們一個一個對應(yīng)的口令还栓，如果這個人不在我手下了碌廓，那么我在我自己的認證端吧他的口令刪除掉就好了。
相信大家已經(jīng)猜到我們要登場的角色了:沒錯剩盒，上面就可以理解為一個簡單版的基于token的auth授權(quán)協(xié)議.現(xiàn)在大多數(shù)的移動服務(wù)端都是基于此種方式來構(gòu)建自己的安全架構(gòu)的.
https
在看完auth協(xié)議的實現(xiàn)架構(gòu)之后谷婆，有心的朋友應(yīng)該發(fā)現(xiàn)問題了，這丫的數(shù)據(jù)不是安全的啊。
問題出在哪里了呢纪挎，就是我在對你的網(wǎng)絡(luò)劫持了之后期贫，我用抓包軟件去抓你的請求，就能拿到你的token异袄，那么我就可以代替你的token來做請求了
臥槽唯灵，這么一聽好危險，那么我們怎么解決這個問題隙轻？
非常簡單埠帕。。玖绿。敛瓷。把我們的服務(wù)器變成https的就好了，那么https是怎么上面的安全問題的呢斑匪？
讓我們先來了解一下https吧
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer）呐籽，是以安全為目標的HTTP通道，簡單講是HTTP的安全版蚀瘸。即HTTP下加入SSL層狡蝶，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL贮勃。 它是一個URI scheme（抽象標識符體系）贪惹，句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸寂嘉。https:URL表明它使用了HTTP奏瞬，但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。
恩泉孩，我想大概你也懂了硼端，其實https就是給我們所有的請求參數(shù)蒙上一層蒙娜麗莎的面具。
簽名驗證
蒙娜麗莎的微笑是那么迷人寓搬，誰又能不陶醉呢珍昨？為了一觀那神秘的微笑，我用盡了全身的力氣句喷。
好了不裝逼了镣典，相信用過Charles的朋友，大概應(yīng)該都能知道脏嚷，他有個功能是也能抓到https的請求包骆撇，那么我們https或許也不是那么安全了，媽個雞的父叙，這可怎么辦神郊，嚇死寶寶了肴裙。
還好本寶寶天資聰慧，想出了一個很好的解決辦法： 參數(shù)簽名涌乳。
那么什么是參數(shù)簽名呢蜻懦？他又能做什么呢？
先說一下怎么去做這個參數(shù)簽名吧夕晓。
我舉個例子：
我有一個請求是這樣的https:aaa.com?a=1&b=2
那么相信你也看到了我請求中的參數(shù)是a=1&b=2,我這時候吧這兩個參數(shù)加上一個字符串我最帥宛乃，變成了這樣a=1&b=2我最帥,然后這個拼接好的字符串就行md5啊，或者sha1之類的單向加密,然后吧單向加密的結(jié)果做為一個參數(shù)sign=sdasfsdfw拼接到之前的請求里
然后我服務(wù)器在接受到請求的時候,吧除了sign之外的參數(shù)做和服務(wù)器一樣的操作蒸辆，也就是生成簽名字符串征炼，然后和傳過來的sign=sdasfsdfw簽名結(jié)果進行對比，如果是相等的說明這個請求是正確的躬贡。
那么我簽名這個有啥用谆奥？這還要我說嗎？當然是防止內(nèi)容篡改拂玻，防止偽造請求酸些。
另外請注意一點：你一定要確保那個sign簽名時候的字符串的(例如之前的我最帥)不被他人知道,例如我們的安卓客戶端可以吧這個打到so庫里。
非對稱加密的藝術(shù)
我靠檐蚜，這時候搞android逆向的朋友不服了,你丫就算給我打到so庫里魄懂，勞資照樣給你弄出來，一個小小的簽名就想難倒我闯第？沒門市栗。
我這時候呵呵一笑，出來混的乡括，沒倆下子怎么好意思裝這個逼呢肃廓，對不對智厌？
那么我這時候簽名都靠不住了诲泌，我咋辦，嗯哼铣鹏，不知道朋友聽沒聽過非對稱加密敷扫。
yeah，我們這里就是要用這種技術(shù)诚卸，這里關(guān)于對稱和非對稱加密的相關(guān)知識不是本文的重點葵第，故不再多提，感興趣的朋友可以自行谷歌合溺。我們這里還是要說一下卒密，怎么用這種加密方式提高安全性。
用過非對稱加密的朋友知道棠赛，這種方式有2個鑰匙哮奇，一個叫公共鑰匙膛腐，一個叫私有鑰匙，我們一般是吧公鑰暴漏在外鼎俘，私鑰存在自己的包里哲身。
在移動端的架構(gòu)一般都是這樣的，生成公鑰和私鑰贸伐，吧公鑰放在客戶端存儲勘天，或者客戶端去拉取。然后把私鑰放在基本處于安全狀態(tài)的服務(wù)器端（如果你說黑客能拿到這屬于服務(wù)器安全問題好伐）捉邢，然后我們在每次請求的時候可以吧參數(shù)用公鑰加密脯丝，然后在服務(wù)器端解密，拿到真正的參數(shù)伏伐。
用了這種方式之后巾钉，保證你自己的代碼，你自己都不知道咋個搞丫秘案，就算你丫牛逼到吧路由器劫持了砰苍，也休想知道我做了啥子撒，哈哈哈哈哈阱高。
