前言

web與后端，andorid與后端，ios與后端，像這種類型的交互其實(shí)就屬于典型的前端與后端進(jìn)行交互。在與B端用戶進(jìn)行交互的過(guò)程中，我們通常忽略了其安全性(甚至從未考慮安全性)。比如，請(qǐng)求和響應(yīng)數(shù)據(jù)的明文傳輸，對(duì)接口并沒(méi)有做嚴(yán)格的身份校驗(yàn)。如果我們還是按照這種思路去做C端用戶的交互，那么等待著必將是血淋淋的教訓(xùn)。接下來(lái)，我?guī)ьI(lǐng)大家如何在與C端用戶安全的進(jìn)行交互。

保證安全性的幾種方式

前后端安全性的交互，大致可以分成如下幾類：

• 通信請(qǐng)求使用https
• 對(duì)請(qǐng)求參數(shù)進(jìn)行簽名，防止數(shù)據(jù)被踹改
• 對(duì)請(qǐng)求參數(shù)以及響應(yīng)進(jìn)行加密解密處理
• APP中使用ssl pinning防止抓包操作

使用https

谷歌 Chrome 在18年七月份已經(jīng)將所有的 HTTP 網(wǎng)站標(biāo)記為“不安全”。并且已經(jīng)有越來(lái)越多的第三方服務(wù)開(kāi)始推薦甚至是強(qiáng)制要求使用 HTTPS 連接方式，比如現(xiàn)在用得特別多的微信登錄、微信支付、短信驗(yàn)證碼、地圖 API 等等，又比如蘋果公司 2016 年在 WWDC 上宣稱，公司希望官方應(yīng)用商店中的所有 iOS App 都使用安全的 HTTPS 鏈接與服務(wù)器進(jìn)行通信。

那為什么越來(lái)越多的 HTTP 都在逐漸 HTTPS 化?HTTP 協(xié)議(超文本傳輸協(xié)議)是客戶端瀏覽器或其他程序與 Web 服務(wù)器之間的應(yīng)用層通信協(xié)議;HTTPS 協(xié)議可以理解為 HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL，用于安全的 HTTP 數(shù)據(jù)傳輸，http與https的區(qū)別如下圖所示：

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來(lái)了三大風(fēng)險(xiǎn)。

• 竊聽(tīng)風(fēng)險(xiǎn)(eavesdropping)：第三方可以獲知通信內(nèi)容。
• 篡改風(fēng)險(xiǎn)(tampering)：第三方可以修改通信內(nèi)容。
• 冒充風(fēng)險(xiǎn)(pretending)：第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議是為了解決這三大風(fēng)險(xiǎn)而設(shè)計(jì)的，希望達(dá)到：

• 所有信息都是加密傳播，第三方無(wú)法竊聽(tīng)。
• 具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。
• 配備身份證書(shū)，防止身份被冒充。

因此強(qiáng)烈建議，為了你的系統(tǒng)安全性，趕快切到https中去吧。

對(duì)請(qǐng)求進(jìn)行簽名

我們先來(lái)看一個(gè)例子，假設(shè)用戶在下完單之后，可以更改訂單的狀態(tài)，用戶對(duì)后端發(fā)起請(qǐng)求 /user?orderId=123, 假設(shè)后端剛好也沒(méi)有對(duì)這筆訂單的身份進(jìn)行驗(yàn)證，那么后果就是，我們根據(jù)orderId, 將這筆訂單的狀態(tài)進(jìn)行了修改：

如果這時(shí)候，嘗試著將請(qǐng)求中的orderId 換成另外一個(gè)orderId, 也會(huì)同樣對(duì)這筆訂單做了修改，從安全角度來(lái)說(shuō)這是我們不希望看到的，當(dāng)然我們也可以加一下身份校驗(yàn)，判斷該筆訂單是否屬于當(dāng)前的用戶;除此之外，我們還應(yīng)該對(duì)請(qǐng)求參數(shù)做一次簽名處理。

加簽和驗(yàn)簽就是在請(qǐng)求發(fā)送方將請(qǐng)求參數(shù)通過(guò)加密算法生成一個(gè)sign值，放到請(qǐng)求參數(shù)里;請(qǐng)求接收方收到請(qǐng)求后，使用同樣的方式對(duì)請(qǐng)求參數(shù)也進(jìn)行加密得到一個(gè)sign值，只要兩個(gè)sign值相同，就說(shuō)明參數(shù)沒(méi)有被篡改。

簽名參數(shù)sign生成的方法

• 將所有以頭參數(shù)(注意時(shí)所有參數(shù))，出去sign本身，以及值是空的參數(shù)，按參數(shù)鍵字母升序排序。
• 然后把排序后的參數(shù)按參數(shù)1值1參數(shù)2值2......參數(shù)n值n(這里的參數(shù)和值必須是傳輸參數(shù)的原始值，不能是經(jīng)過(guò)處理的，如不能將"轉(zhuǎn)成"后再拼接)的方式拼接成一個(gè)字符串。
• 把分配給接入方的驗(yàn)證密鑰key拼接在第2步得到的字符串前面。
• 在上一步得到的字符串前面加上密鑰key(這里的密鑰key是接口提供方分配給接口接入方的)，然后計(jì)算md5值，得到32位字符串，然后轉(zhuǎn)成大寫,得到的字符串作為sign的值放到請(qǐng)求參數(shù)里。

舉例

現(xiàn)在假設(shè)需要傳輸?shù)臄?shù)據(jù):/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn(實(shí)際情況最好是通過(guò)post方式發(fā)送)

• 拼接字符串，首先去除值是空的參數(shù)p3，剩下p2=v2&p1=v1&method=cancel&pn=vn，然后按參數(shù)名字符升序排序得到字符串：method=cancel&p1=v1&p2=v2&pn=vn。
• 然后做參數(shù)名和值的拼接，最后得到methodcancelp1v1p2v2pnvn。
• 在上面拼接得到的字符串前面加上驗(yàn)證密鑰key，假設(shè)是abc，得到新的字符串a(chǎn)bcmethodcancelp1v1p2v2pnvn。
• 將上面得到的字符串進(jìn)行md5計(jì)算，假設(shè)得到的是abcdef，然后轉(zhuǎn)為大寫，得到ABCDEF這個(gè)值即為sign簽名值。最終產(chǎn)生的url應(yīng)該如下：/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn&sign=ABCDEF

注意：計(jì)算md5之前請(qǐng)確保請(qǐng)求發(fā)送方和接收方使用的字符串編碼一致，比如統(tǒng)一使用utf-8編碼，如果編碼方式不一致則計(jì)算出來(lái)的簽名會(huì)校驗(yàn)失敗。

驗(yàn)簽過(guò)程

其實(shí)就是將請(qǐng)求url按照上述的規(guī)則進(jìn)行同樣的操作，計(jì)算得到參數(shù)的簽名值，然后和參數(shù)中傳遞的sign值進(jìn)行對(duì)比，如果一致則校驗(yàn)通過(guò)，否則校驗(yàn)不通過(guò)。

對(duì)請(qǐng)求和響應(yīng)進(jìn)行加解密

可能有人會(huì)問(wèn)，都使用了https了，為什么還要對(duì)請(qǐng)求和響應(yīng)再做一次加解密，因?yàn)橛行┑谌阶グぞ?，例如Charles 通過(guò)某些手段是可以抓取https的明文的，因此對(duì)一些敏感數(shù)據(jù)，我們需要進(jìn)行加密處理，常見(jiàn)的加解密方式有AES 對(duì)成加密方式和RSA非對(duì)成方式，至于如何運(yùn)用，可以參考https的原理，有點(diǎn)復(fù)雜，不過(guò)可以簡(jiǎn)單分成如下幾步：

[[284521]]

• 服務(wù)器端有一個(gè)密鑰對(duì)，即公鑰和私鑰，是用來(lái)進(jìn)行非對(duì)稱加密使用的，服務(wù)器端保存著私鑰，不能將其泄露，公鑰可以發(fā)送給任何人。
• 服務(wù)器將自己的公鑰發(fā)送給客戶端。
• 客戶端收到服務(wù)器端的公鑰之后，會(huì)對(duì)公鑰進(jìn)行檢查，驗(yàn)證其合法性，如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問(wèn)題，那么HTTPS傳輸就無(wú)法繼續(xù)。嚴(yán)格的說(shuō)，這里應(yīng)該是驗(yàn)證服務(wù)器發(fā)送的數(shù)字證書(shū)的合法性，關(guān)于客戶端如何驗(yàn)證數(shù)字證書(shū)的合法性，下文會(huì)進(jìn)行說(shuō)明。如果公鑰合格，那么客戶端會(huì)生成一個(gè)隨機(jī)值，這個(gè)隨機(jī)值就是用于進(jìn)行對(duì)稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，這樣在概念上和服務(wù)器端的密鑰容易進(jìn)行區(qū)分。然后用服務(wù)器的公鑰對(duì)客戶端密鑰進(jìn)行非對(duì)稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請(qǐng)求結(jié)束。
• 客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。
• 服務(wù)器接收到客戶端發(fā)來(lái)的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對(duì)數(shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文。
• 然后服務(wù)器將加密后的密文發(fā)送給客戶端。
• 客戶端收到服務(wù)器發(fā)送來(lái)的密文，用客戶端密鑰對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器發(fā)送的數(shù)據(jù)。

總結(jié)

前后端的交互如果做到以上使用https，對(duì)請(qǐng)求加解密以及對(duì)請(qǐng)求參數(shù)進(jìn)行驗(yàn)簽，基本上能解決大部分問(wèn)題，但除此之外我們還應(yīng)該做到對(duì)每個(gè)接口進(jìn)行身份校驗(yàn)，確保該接口只能由特定的用戶訪問(wèn)，或者該筆數(shù)據(jù)只能由特定的用戶去進(jìn)行修改。