前言
大家好呀，我是撿田螺的小男孩。
我們日常開發中，如何保證介面資料的安全性呢？個人覺得，介面資料安全的保證過程，主要體現在這幾個方面：一個就是資料傳輸過程中的安全，還有就是資料到達服務端，如何識別資料，最後一點就是資料儲存的安全性。今天跟大家聊聊保證介面資料安全的 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. 限流機制
如果使用者本來就是就是真實使用者，他惡意頻繁呼叫介面，想搞垮你的系統呢？這種情況就需要接入限流了。
常用的限流演算法有令牌桶和漏桶演算法。大家可以看下我的這篇文章，面試必備：4 種經典限流演算法講解
可以使用Guava的RateLimiter單機版限流，也可以使用Redis分散式限流，還可以使用阿里開源元件sentinel限流。比如說，一分鐘可以接受多少次請求。
7. 黑名單機制
如果發現了真實使用者惡意請求,你可以搞個黑名單機制，把該使用者拉黑。一般情況，會有些競爭對手，或者不懷好意的使用者，想搞你的系統的。所以，為了保證安全，一般我們的業務系統，需要有個黑名單機制。對於黑名單發起的請求，直接返回錯誤碼好了。
8.白名單機制
有了黑名單機制，也可以搞個白名單機制啦。以前我負責的企業轉帳系統，如果有外面的商戶要接入我們的系統時，是需要提前申請網路白名單的。那時候運維會申請個 IP 網路白名單，只有白名單裡面的請求，才可以存取我們的轉帳系統。
9.資料脫敏遮罩
對於密碼，或者手機號、身分證這些敏感資訊，一般都需要脫敏遮罩再展示的，如果是密碼，還需要加密再儲存到資料庫。
對於手機號、身分證資訊這些，日常開發中，在日誌排查時，看到的都應該是遮罩的。目的就是盡量不洩露這些使用者資訊，雖然能看日誌的只是開發和運維，但是還是需要防一下，做遮罩處理。
對於密碼儲存到資料庫，我們肯定不能直接明文儲存。最簡單的也需要MD5處理一下再儲存，Spring Security中的 BCryptPasswordEncoder也可以，它的底層是採用SHA-256 +隨機鹽+金鑰對密碼進行加密，而SHA和MD系列是一樣的，都是hash摘要類的演算法。
10. 資料參數一些合法性校驗。
介面資料的安全性保證，還需要我們的系統，有個資料合法性校驗，簡單來說就是參數校驗，比如身分證長度，手機號長度，是否是數字等等。
總結
本文給大家介紹了 10 種保證介面資料安全的方案。小夥伴們，如有還有其他方案的話，可以在留言區評論哈，一起交流學習。