### 前言 我們日常開發中，如何保證接口數據的安全性呢？個人覺得，接口數據安全的保證過程，主要體現在這幾個方面：一個就是**數據傳輸**過程中的安全，還有就是數據到達服務端，如何**識別數據**，最后一點就是**數據存儲的安全性**。今天跟大家聊聊保證接口數據安全的10個方案。  ### 1.數據加密，防止報文明文傳輸。 我們都知道，數據在網絡傳輸過程中，很容易被抓包。如果使用的是http協議，因為它是明文傳輸的，用戶的數據就很容易被別人獲取。所以需要對數據加密。 ### 1.1 數據如何加密呢？ 常見的實現方式，就是對**關鍵字段**加密。比如，你一個登錄的接口，你可以對**密碼**加密。一般用什么加密算法呢？簡單點可以使用**對稱加密算法**（如AES）來加解密，或者哈希算法處理（如MD5）。 > 什么是**對稱加密**：加密和解密使用相同密鑰的加密算法。  > **非對稱加密**：非對稱加密算法需要兩個密鑰（公開密鑰和私有密鑰）。**公鑰與私鑰是成對存在的**，如果用公鑰對數據進行加密，只有對應的私鑰才能解密。 更安全的做法，就是用**非對稱加密算法**（如RSA或者SM2），公鑰加密，私鑰解密。  如果你想對所有字段都加密的話，一般都推薦使用**https協議**。https其實就是在http和tcp之間添加一層加密層SSL。 ### 1.2 小伙伴們，是否還記得https的原理呢？ 面試也經常問的，如下：  1. 客戶端發起Https請求，連接到服務器的443端口。 2. 服務器必須要有一套數字證書（證書內容有公鑰、證書頒發機構、失效日期等）。 3. 服務器將自己的數字證書發送給客戶端（公鑰在證書里面，私鑰由服務器持有）。 4. 客戶端收到數字證書之后，會驗證證書的合法性。如果證書驗證通過，就會生成一個隨機的對稱密鑰，用證書的公鑰加密。 5. 客戶端將公鑰加密后的密鑰發送到服務器。 6. 服務器接收到客戶端發來的密文密鑰之后，用自己之前保留的私鑰對其進行非對稱解密，解密之后就得到客戶端的密鑰，然后用客戶端密鑰對返回數據進行對稱加密，醬紫傳輸的數據都是密文啦。 7. 服務器將加密后的密文返回到客戶端。 8. 客戶端收到后，用自己的密鑰對其進行對稱解密，得到服務器返回的數據。 日常業務呢，數據傳輸加密這塊的話，用**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登錄授權流程圖如下：**  1. 用戶輸入用戶名和密碼，發起登錄請求 2. 服務端校驗密碼，如果校驗通過，生成一個全局唯一的token。 3. 將token存儲在redis中，其中key是token，value是userId或者是用戶信息，設置一個過期時間。 4. 把這個token返回給客戶端 5. 用戶發起其他業務請求時，需要帶上這個token 6. 后臺服務會統一攔截接口請求，進行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\. 限流機制 如果用戶本來就是就是真實用戶，他惡意頻繁調用接口，想搞垮你的系統呢？這種情況就需要接入限流了。 常用的限流算法有令牌桶和漏桶算法。大家可以看下我的這篇文章，面試必備：4種經典限流算法講解 可以使用Guava的RateLimiter單機版限流，也可以使用Redis分布式限流，還可以使用阿里開源組件sentinel限流。比如說，一分鐘可以接受多少次請求。 ### 7\. 黑名單機制 如果發現了真實用戶惡意請求,你可以搞個黑名單機制，把該用戶拉黑。一般情況，會有些競爭對手，或者不壞好意的用戶，想搞你的系統的。所以，為了保證安全，一般我們的業務系統，需要有個黑名單機制。對于黑名單發起的請求，直接返回錯誤碼好了。 ### 8.白名單機制 有了黑名單機制，也可以搞個白名單機制啦。以前我負責的企業轉賬系統，如果有外面的商戶要接入我們的系統時，是需要提前申請網絡白名單的。那時候運維會申請個IP網絡白名單，只有白名單里面的請求，才可以訪問我們的轉賬系統。 ### 9.數據脫敏掩碼 對于密碼，或者手機號、身份證這些敏感信息，一般都需要脫敏掩碼再展示的，如果是密碼，還需要加密再保存到數據庫。 對于手機號、身份證信息這些，日常開發中，在日志排查時，看到的都應該是掩碼的。目的就是盡量不泄漏這些用戶信息，雖然能看日志的只是開發和運維，但是還是需要防一下，做掩碼處理。 對于密碼保存到數據庫，我們肯定不能直接明文保存。最簡單的也需要MD5處理一下再保存，Spring Security中的 BCryptPasswordEncoder也可以，它的底層是采用SHA-256 +隨機鹽+密鑰對密碼進行加密，而SHA和MD系列是一樣的，都是hash摘要類的算法。 ### 10\. 數據參數一些合法性校驗。 接口數據的安全性保證，還需要我們的系統，有個數據合法性校驗，簡單來說就是**參數校驗**，比如身份證長度，手機號長度，是否是數字等等。