前言

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

保證安全性的幾種方式

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

1、通信請求使用https

2、對請求參數進(jìn)行簽名，防止數據被踹改

3、對請求參數以及響應進(jìn)行加密解密處理

4、APP中使用 pinning防止抓包操作

使用https

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

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

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

/TLS協(xié)議是為了解決這三大風(fēng)險而設計的，希望達到：

因此強烈建議，為了你的系統安全性，趕快切到https中去吧。

對請求進(jìn)行簽名

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

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

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

簽名參數sign生成的方法

舉例

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

驗簽過(guò)程

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

對請求和響應進(jìn)行加解密

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

1.服務(wù)器端有一個(gè)密鑰對，即公鑰和私鑰，是用來(lái)進(jìn)行非對稱(chēng)加密使用的，服務(wù)器端保存著(zhù)私鑰，不能將其泄露，公鑰可以發(fā)送給任何人。

2.服務(wù)器將自己的公鑰發(fā)送給客戶(hù)端。

3.客戶(hù)端收到服務(wù)器端的公鑰之后，會(huì )對公鑰進(jìn)行檢查，驗證其合法性，如果發(fā)現發(fā)現公鑰有問(wèn)題，那么HTTPS傳輸就無(wú)法繼續。嚴格的說(shuō)，這里應該是驗證服務(wù)器發(fā)送的ssl/' target='_blank'>數字證書(shū)的合法性，關(guān)于客戶(hù)端如何驗證數字證書(shū)的合法性，下文會(huì )進(jìn)行說(shuō)明。如果公鑰合格，那么客戶(hù)端會(huì )生成一個(gè)隨機值，這個(gè)隨機值就是用于進(jìn)行對稱(chēng)加密的密鑰，我們將該密鑰稱(chēng)之為client key，即客戶(hù)端密鑰，這樣在概念上和服務(wù)器端的密鑰容易進(jìn)行區分。然后用服務(wù)器的公鑰對客戶(hù)端密鑰進(jìn)行非對稱(chēng)加密，這樣客戶(hù)端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請求結束。

4.客戶(hù)端會(huì )發(fā)起HTTPS中的第二個(gè)HTTP請求，將加密之后的客戶(hù)端密鑰發(fā)送給服務(wù)器。

5.服務(wù)器接收到客戶(hù)端發(fā)來(lái)的密文之后，會(huì )用自己的私鑰對其進(jìn)行非對稱(chēng)解密，解密之后的明文就是客戶(hù)端密鑰，然后用客戶(hù)端密鑰對數據進(jìn)行對稱(chēng)加密，這樣數據就變成了密文。

6.然后服務(wù)器將加密后的密文發(fā)送給客戶(hù)端。

7.客戶(hù)端收到服務(wù)器發(fā)送來(lái)的密文，用客戶(hù)端密鑰對其進(jìn)行對稱(chēng)解密，得到服務(wù)器發(fā)送的數據。

總結

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