前言

最近有個專案需要對外提供一個介面，提供公網域名進行訪問，而且介面和交易訂單有關，所以安全性很重要；這裡整理了一下常用的一些安全措施以及具體如何去實現。

安全措施

個人覺得安全措施大體來看主要在兩個方面：

1. 一方面就是如何保證資料在傳輸過程中的安全性；
2. 另一個方面是資料已經到達伺服器端，伺服器端如何識別資料，如何不被攻擊；下面具體看看都有哪些安全措施。

1.資料加密

我們知道資料在傳輸過程中是很容易被抓包的，如果直接傳輸比如通過http協議，那麼使用者傳輸的資料可以被任何人獲取；所以必須對資料加密，常見的做法對關鍵欄位加密比如使用者密碼直接通過md5加密；現在主流的做法是使用https協議，在http和tcp之間新增一層加密層(SSL層)，這一層負責資料的加密和解密；

2.資料加簽

資料加簽就是由傳送者產生一段無法偽造的一段數字串，來保證資料在傳輸過程中不被篡改；你可能會問資料如果已經通過https加密了，還有必要進行加簽嗎？資料在傳輸過程中經過加密，理論上就算被抓包，也無法對資料進行篡改；但是我們要知道加密的部分其實只是在外網，現在很多服務在內網中都需要經過很多服務跳轉，所以這裡的加簽可以防止內網中資料被篡改；

3.時間戳機制

資料是很容易被抓包的，但是經過如上的加密，加簽處理，就算拿到資料也不能看到真實的資料；但是有不法者不關心真實的資料，而是直接拿到抓取的資料包進行惡意請求；這時候可以使用時間戳機制，在每次請求中加入當前的時間，伺服器端會拿到當前時間和訊息中的時間相減，看看是否在一個固定的時間範圍內比如5分鐘內；這樣惡意請求的資料包是無法更改裡面時間的，所以5分鐘後就視為非法請求了；

4.AppId機制

大部分網站基本都需要使用者名稱和密碼才能登入，並不是誰來能使用我的網站，這其實也是一種安全機制；對應的對外提供的介面其實也需要這麼一種機制，並不是誰都可以呼叫，需要使用介面的使用者需要在後臺開通appid，提供給使用者相關的金鑰；在呼叫的介面中需要提供 appid+金鑰，伺服器端會進行相關的驗證；

5.限流機制

本來就是真實的使用者，並且開通了appid，但是出現頻繁呼叫介面的情況；這種情況需要給相關appid限流處理，常用的限流演算法有令牌桶和漏桶演算法；

6.黑名單機制

如果此appid進行過很多非法操作，或者說專門有一箇中黑系統，經過分析之後直接將此appid列入黑名單，所有請求直接返回錯誤碼；

7.資料合法性校驗

這個可以說是每個系統都會有的處理機制，只有在資料是合法的情況下才會進行資料處理；每個系統都有自己的驗證規則，當然也可能有一些常規性的規則，比如身份證長度和組成，電話號碼長度和組成等等；

如何實現

以上大體介紹了一下常用的一些介面安全措施，當然可能還有其他我不知道的方式，希望大家補充，下面看看以上這些方法措施，具體如何實現；

1.資料加密

現在主流的加密方式有對稱加密和非對稱加密

1. 對稱加密：對稱金鑰在加密和解密的過程中使用的金鑰是相同的，常見的對稱加密演算法有DES，AES；優點是計算速度快，缺點是在資料傳送前，傳送方和接收方必須商定好祕鑰，然後使雙方都能儲存好祕鑰，如果一方的祕鑰被洩露，那麼加密資訊也就不安全了；
2. 非對稱加密：服務端會生成一對金鑰，私鑰存放在伺服器端，公鑰可以釋出給任何人使用；優點就是比起對稱加密更加安全，但是加解密的速度比對稱加密慢太多了；廣泛使用的是RSA演算法；

兩種方式各有優缺點，而https的實現方式正好是結合了兩種加密方式，整合了雙方的優點，在安全和效能方面都比較好；對稱加密和非對稱加密程式碼實現，jdk提供了相關的工具類可以直接使用，此處不過多介紹；關於https如何配置使用相對來說複雜一些，可以參考本人的之前的文章HTTPS分析與實戰

2.資料加簽

資料簽名使用比較多的是md5演算法，將需要提交的資料通過某種方式組合和一個字串，然後通過md5生成一段加密字串，這段加密字串就是資料包的簽名，可以看一個簡單的例子：

str：引數1={引數1}&引數2={引數2}&……&引數n={引數n}$key={使用者金鑰};
MD5.encrypt(str);

注意最後的使用者金鑰，客戶端和服務端都有一份，這樣會更加安全；

3.時間戳機制

解密後的資料，經過簽名認證後，我們拿到資料包中的客戶端時間戳欄位，然後用伺服器當前時間去減客戶端時間，看結果是否在一個區間內，虛擬碼如下：

long interval=5*60*1000；//超時時間
long clientTime=request.getparameter("clientTime");
long serverTime=System.currentTimeMillis();
if(serverTime-clientTime>interval){
    return new Response("超過處理時長")
}

4.AppId機制

生成一個唯一的AppId即可，金鑰使用字母、數字等特殊字元隨機生成即可；生成唯一AppId根據實際情況看是否需要全域性唯一；但是不管是否全域性唯一最好讓生成的Id有如下屬性：

1. 趨勢遞增：這樣在儲存資料庫的時候，使用索引效能更好；
2. 資訊保安：儘量不要連續的，容易發現規律；

關於全域性唯一Id生成的方式常見的有類snowflake方式等；

5.限流機制

常用的限流演算法包括：固定視窗計數器演算法、滑動視窗計數器演算法、漏桶限流、令牌桶限流

固定視窗計數器演算法

規定我們單位時間處理的請求數量。比如我們規定我們的一個介面一分鐘只能訪問10次的話。使用固定視窗計數器演算法的話可以這樣實現：給定一個變數counter來記錄處理的請求數量，當1分鐘之內處理一個請求之後counter+1，1分鐘之內的如果counter=100的話，後續的請求就會被全部拒絕。等到 1分鐘結束後，將counter迴歸成0，重新開始計數（ps：只要過了一個週期就講counter迴歸成0）。這種限流演算法無法保證限流速率，因而無法保證突然激增的流量。比如我們限制一個介面一分鐘只能訪問10次的話，前半分鐘一個請求沒有接收，後半分鐘接收了10個請求。固定視窗計數器演算法

滑動視窗計數器演算法

算的上是固定視窗計數器演算法的升級版。滑動視窗計數器演算法相比於固定視窗計數器演算法的優化在於：它把時間以一定比例分片比如一分鐘分為6個區間，每個區間為10s。每過一定區間的時間，就拋棄最前面的一個區間，如下圖所示。如果當前視窗的請求數量超過了限制數量的話，就拒絕後續請求。

很顯然：當滑動視窗的格子劃分的越多，滑動視窗的滾動就越平滑，限流的統計就會越精確。

漏桶演算法

我們可以把發請求的動作比作成注水到桶中，我們處理請求的過程可以比喻為漏桶漏水。我們往桶中以任意速率流入水，以一定速率流出水。當水超過桶流量則丟棄，因為桶容量是不變的，保證了整體的速率。如果想要實現這個演算法的話也很簡單，準備一個佇列用來儲存請求，然後我們定期從佇列中拿請求來執行就好了。

令牌桶演算法

令牌桶演算法也比較簡單。和漏桶演算法演算法一樣，我們的主角還是桶（這限流演算法和桶過不去啊）。不過現在桶裡裝的是令牌了，請求在被處理之前需要拿到一個令牌，請求處理完畢之後將這個令牌丟棄（刪除）。我們根據限流大小，按照一定的速率往桶裡新增令牌。

具體基於以上演算法如何實現，Guava提供了RateLimiter工具類基於基於令牌桶演算法：

RateLimiter rateLimiter = RateLimiter.create(5);

以上程式碼表示一秒鐘只允許處理五個併發請求，以上方式只能用在單應用的請求限流，不能進行全侷限流；這個時候就需要分散式限流，可以基於redis+lua來實現；

6.黑名單機制

如何為什麼中黑我們這邊不討論，我們可以給每個使用者設定一個狀態比如包括：初始化狀態，正常狀態，中黑狀態，關閉狀態等等；或者我們直接通過分散式配置中心，直接儲存黑名單列表，每次檢查是否在列表中即可；

7.資料合法性校驗

合法性校驗包括：

1. 常規性校驗：包括簽名校驗，必填校驗，長度校驗，型別校驗，格式校驗等；

2. 業務校驗：根據實際業務而定，比如訂單金額不能小於0等；