介面資料安全保證的10種方式

2022-07-06 18:00:19

引言

我們日常開發中，如何保證介面資料的安全性呢？個人覺得，介面資料安全的保證過程，主要體現在這幾個方面：一個就是資料傳輸過程中的安全，還有就是資料到達伺服器端，如何識別資料，最後一點就是資料儲存的安全性。今天跟大家聊聊保證介面資料安全的10個方案。

1.資料加密，防止報文明文傳輸。

我們都知道，資料在網路傳輸過程中，很容易被抓包。如果使用的是http協定，因為它是明文傳輸的，使用者的資料就很容易被別人獲取。所以需要對資料加密。

1.1 資料如何加密呢？

常見的實現方式，就是對關鍵欄位加密。比如，你一個登入的介面，你可以對密碼加密。一般用什麼加密演演算法呢？簡單點可以使用對稱加密演演算法（如AES）來加解密，或者雜湊演演算法處理（如MD5）。

什麼是對稱加密：加密和解密使用相同金鑰的加密演演算法。

非對稱加密：非對稱加密演演算法需要兩個金鑰（公開金鑰和私有金鑰）。公鑰與私鑰是成對存在的，如果用公鑰對資料進行加密，只有對應的私鑰才能解密。

更安全的做法，就是用非對稱加密演演算法（如RSA或者SM2），公鑰加密，私鑰解密。

如果你想對所有欄位都加密的話，一般都推薦使用https協定。https其實就是在http和tcp之間新增一層加密層SSL。

1.2 小夥伴們，是否還記得https的原理呢？

面試也經常問的，如下：

使用者端發起Https請求，連線到伺服器的443埠。
伺服器必須要有一套數位憑證（證書內容有公鑰、證書頒發機構、失效日期等）。
伺服器將自己的數位憑證傳送給使用者端（公鑰在證書裡面，私鑰由伺服器持有）。
使用者端收到數位憑證之後，會驗證證書的合法性。如果證書驗證通過，就會生成一個隨機的對稱金鑰，用證書的公鑰加密。
使用者端將公鑰加密後的金鑰傳送到伺服器。
伺服器接收到使用者端發來的密文金鑰之後，用自己之前保留的私鑰對其進行非對稱解密，解密之後就得到使用者端的金鑰，然後用使用者端金鑰對返回資料進行對稱加密，醬紫傳輸的資料都是密文啦。
伺服器將加密後的密文返回到使用者端。
使用者端收到後，用自己的金鑰對其進行對稱解密，得到伺服器返回的資料。

日常業務呢，資料傳輸加密這塊的話，用https就可以啦，如果安全性要求較高的，比如登陸註冊這些，需要傳輸密碼的，密碼就可以使用RSA等非對稱加密演演算法，對密碼加密。如果你的業務，安全性要求很高，你可以模擬https這個流程，對報文，再做一次加解密。

2. 資料加簽驗籤

資料包文加簽驗籤，是保證資料傳輸安全的常用手段，它可以保證資料在傳輸過程中不被篡改。以前我做的企業轉賬系統，就用了加簽驗籤。

2.1 什麼是加簽驗籤呢？

資料加簽：用Hash演演算法（如MD5，或者SHA-256）把原始請求引數生成報文摘要，然後用私鑰對這個摘要進行加密，就得到這個報文對應的數位簽章sign（這個過程就是加簽）。通常來說呢，請求方會把數位簽章和報文原文一併行送給接收方。

驗籤：接收方拿到原始報文和數位簽章（sign）後，用同一個Hash演演算法(比如都用MD5)從報文中生成摘要A。另外，用對方提供的公鑰對數位簽章進行解密，得到摘要B，對比A和B是否相同，就可以得知報文有沒有被篡改過。

其實加簽，我的理解的話，就是把請求引數，按照一定規則，利用hash演演算法+加密演演算法生成一個唯一標籤sign。驗籤的話，就是把請求引數按照相同的規則處理，再用相同的hash演演算法，和對應的金鑰解密處理，以對比這個簽名是否一致。

再舉個例子，有些小夥伴是這麼實現的，將所有非空引數（包含一個包AccessKey，唯一的開發者標識）按照升序，然後再拼接個SecretKey（這個僅作本地加密使用，不參與網路傳輸，它只是用作簽名裡面的），得到一個stringSignTemp的值，最後用MD5運算，得到sign。

伺服器端收到報文後，會校驗，只有擁有合法的身份AccessKey和簽名Sign正確，才放行。這樣就解決了身份驗證和引數篡改問題，如果請求引數被劫持，由於劫持者獲取不到SecretKey（僅作本地加密使用，不參與網路傳輸），他就無法偽造合法的請求啦

2.2 有了https等加密資料，為什麼還需要加簽驗籤

有些小夥伴可能有疑問，加簽驗籤主要是防止資料在傳輸過程中被篡改，那如果都用了https下協定加密資料了，為什麼還會被篡改呢？為什麼還需要加簽驗籤呢？

資料在傳輸過程中被加密了，理論上，即使被抓包，資料也不會被篡改。但是https不是絕對安全的哦。可以看下這個文章：可怕，原來 HTTPS 也沒用。還有一個點：https加密的部分只是在外網，然後有很多服務是內網相互跳轉的，加簽也可以在這裡保證不被中間人篡改，所以一般轉賬類安全性要求高的介面開發，都需要加簽驗籤

3.token授權認證機制

日常開發中，我們的網站或者APP，都是需要使用者登入的。那麼如果是非登入介面，是如何確保安全，如何確認使用者身份的呢？可以使用token授權機制。

3.1 token的授權認證方案

token的授權認證方案：使用者在使用者端輸入使用者名稱和密碼，點選登入後，伺服器會校驗密碼成功，會給使用者端返回一個唯一值token，並將token以鍵值對的形式存放在快取（一般是Redis）中。後續使用者端對需要授權模組的所有操作都要帶上這個token，伺服器端接收到請求後，先進行token驗證，如果token存在，才表明是合法請求。

token登入授權流程圖如下：

使用者輸入使用者名稱和密碼，發起登入請求
伺服器端校驗密碼，如果校驗通過，生成一個全域性唯一的token。
將token儲存在redis中，其中key是token，value是userId或者是使用者資訊，設定一個過期時間。
把這個token返回給使用者端
使用者發起其他業務請求時，需要帶上這個token
後臺服務會統一攔截介面請求，進行token有效性校驗，並從中獲取使用者資訊，供後續業務邏輯使用。如果token不存在，說明請求無效。

3.2 如何保證token的安全？token被劫持呢？

我們如何保證token的安全呢？

比如說，我如果拿到token，是不是就可以呼叫伺服器端的任何介面？可以從這幾個方面出發考慮：

token設定合理的有效期
使用https協定
token可以再次加密
如果存取的是敏感資訊，單純加token是不夠的，通常會再設定白名單

說到token，有些小夥伴們可能會想起jwt，即（JSON Web Token），其實它也是token的一種。有興趣的小夥伴可以去了解一下哈。

4. 時間戳timestamp超時機制

資料是很容易抓包的，假設我們用了https和加簽，即使中間人抓到了資料包文，它也看不到真實資料。但是有些不法者，他根本不關心真實的資料，而是直接拿到抓取的封包，進行惡意請求（比如DOS攻擊），以搞垮你的系統。

我們可以引入時間戳超時機制，來保證介面安全。就是：使用者每次請求都帶上當前時間的時間戳timestamp，伺服器端接收到timestamp後，解密，驗籤通過後，與伺服器當前時間進行比對，如果時間差大於一定時間 (比如3分鐘)，則認為該請求無效。

5.timestamp+nonce方案防止重放攻擊

時間戳超時機制也是有漏洞的，如果是在時間差內，駭客進行的重放攻擊，那就不好使了。可以使用timestamp+nonce方案。

nonce指唯一的隨機字串，用來標識每個被簽名的請求。我們可以將每次請求的nonce引數儲存到一個“set集合”中，或者可以json格式儲存到資料庫或快取中。每次處理HTTP請求時，首先判斷該請求的nonce引數是否在該“集合”中，如果存在則認為是非法請求。

然而對伺服器來說，永久儲存nonce的代價是非常大的。可以結合timestamp來優化。因為timstamp引數對於超過3min的請求，都認為非法請求，所以我們只需要儲存3min的nonce引數的“集合”即可。

6. 限流機制

如果使用者本來就是就是真實使用者，他惡意頻繁呼叫介面，想搞垮你的系統呢？這種情況就需要接入限流了。

常用的限流演演算法有令牌桶和漏桶演演算法。大家可以看下我的這篇文章，面試必備：經典限流演演算法講解

可以使用Guava的RateLimiter單機版限流，也可以使用Redis分散式限流，還可以使用阿里開源元件sentinel限流。比如說，一分鐘可以接受多少次請求。

7. 黑名單機制

如果發現了真實使用者惡意請求,你可以搞個黑名單機制，把該使用者拉黑。一般情況，會有些競爭對手，或者不壞好意的使用者，想搞你的系統的。所以，為了保證安全，一般我們的業務系統，需要有個黑名單機制。對於黑名單發起的請求，直接返回錯誤碼好了。

8.白名單機制

有了黑名單機制，也可以搞個白名單機制啦。以前我負責的企業轉賬系統，如果有外面的商戶要接入我們的系統時，是需要提前申請網路白名單的。那時候運維會申請個IP網路白名單，只有白名單裡面的請求，才可以存取我們的轉賬系統。

9.資料脫敏掩碼

對於密碼，或者手機號、身份證這些敏感資訊，一般都需要脫敏掩碼再展示的，如果是密碼，還需要加密再儲存到資料庫。

對於手機號、身份證資訊這些，日常開發中，在紀錄檔排查時，看到的都應該是掩碼的。目的就是儘量不洩漏這些使用者資訊，雖然能看紀錄檔的只是開發和運維，但是還是需要防一下，做掩碼處理。

對於密碼儲存到資料庫，我們肯定不能直接明文儲存。最簡單的也需要MD5處理一下再儲存，Spring Security中的 BCryptPasswordEncoder也可以，它的底層是採用SHA-256 +隨機鹽+金鑰對密碼進行加密，而SHA和MD系列是一樣的，都是hash摘要類的演演算法。