接口安全11招，真香！
前言
最近知識星球中有位小伙伴問了我一個問題：如何保證接口的安全性？
根據我多年的工作經驗，這篇文章從11個方面給大家介紹一下保證接口安全的一些小技巧，希望對你會有所幫助。
圖片
1 參數校驗
保證接口安全的第一步，也是最重要的一步，需要對接口的請求參數做校驗。
如果我們把接口請求參數的校驗做好了，真的可以攔截大部分的無效請求。
我們可以按如下步驟做校驗：
- 校驗參數是否為空，有些接口中可能會包含多個參數，有些參數允許為空，有些參數不允許為空，我們需要對這些參數做校驗，防止接口底層出現異常。
- 校驗參數類型，比如：age是int類型的，用戶傳入了一個字符串："123abc"，這種情況參數不合法，需要被攔截。
- 校驗參數的長度，特別是對于新增或者修改數據接口，必須要做參數長度的校驗，否則超長了數據庫會報異常。比如：數據庫username字段長度是30，新用戶注冊時，輸入了超過30個字符的名稱，需要提示用戶名稱超長了。雖說前端會校驗字段長度，但接口對參數長度的校驗也必不可少。
- 校驗枚舉值，有些接口參數是枚舉，比如：status，數據庫中設計的該字段只有1、2、3三個值。如果用戶傳入了4，則需要提示用戶參數錯誤。
- 校驗數據范圍，對于有些金額參數，需要校驗數據范圍，比如：單筆交易的money必須大于0，小于10000。
我們可以自己寫代碼，對每個接口的請求參數一一做校驗。
也可以使用一些第三方的校驗框架。
比如：hiberate的Validator框架，它里面包含了@Null、@NotEmpty、@Size、@Max、@Min等注解。
用它們校驗數據非常方便。
當然有些日期字段和枚舉字段，可能需要通過自定義注解的方式實現參數校驗。
2 統一封裝返回值
可能有些小伙伴認為，對接口返回值統一封裝是為了讓代碼更規范。
其實也是處于安全方面的考慮。
假如有這樣一種場景：你寫的某個接口底層的sql，在某種條件下有語法問題。某個用戶請求接口之后，在訪問數據庫時，直接報了sql語法錯誤，將數據庫名、表名、字段名、相關sql語句都打印出來了。
此時，如果你的接口將這些異常信息直接返回給外網的用戶，有些黑客拿著這些信息，將參數做一些調整，拼接一些注入sql，可以對你的數據庫發起攻擊。
因此，非常有必要對接口的返回值做統一的封裝。
例如下面這樣：
{
"code":0,
"message":null,
"data":[{"id":123,"name":"abc"}]
}該json返回值中定義了三個字段：
- code：表示響應碼，0-成功，1-參數為空，2-參數錯誤，3-簽名錯誤 4-請求超時 5-服務器內部錯誤等。
- message：表示提示信息，如果請求成功，則返回空。如果請求失敗，則返回我們專門在代碼中處理過，讓用戶能看懂的錯誤信息。
- data：表示具體的數據，返回的是一個json字段。
對返回值這樣封裝之后，即使在接口的底層出現了數據庫的異常，也不會直接提示用戶，給用戶提示的是服務器內部錯誤。
對返回值統一封裝的工作，沒有必要在業務代碼中做，完全可以在放到API網關。
業務系統在出現異常時，拋出業務異常的RuntimeException，其中有個message字段定義異常信息。
所有的API接口都必須經過API網關，API網關捕獲該業務異常，然后轉換成統一的異常結構返回，這樣能統一返回值結構。
3 做轉義
在用戶自定義輸入框，用戶可以輸入任意內容。
有些地方需要用html的格式顯示用戶輸入的內容，比如文章詳情頁或者合同詳情頁，用戶可以自定義文案和樣式。
這些地方如果我們不做處理，可能會遭受XSS（Cross Site Scripting）攻擊，也就是跨站腳本攻擊。
攻擊者可以在輸入的內容中，增加腳本，比如：<script>alert("反射型 XSS 攻擊")</script>，這樣在訪問合同詳情頁時，會彈出一個不需要的窗口，攻擊者甚至可以引導用戶訪問一些惡意的鏈接。
由此，我們需要對用戶輸入內容中的一些特殊標簽做轉義。
下面這張圖中列出了需要轉義的常見字符和轉義后的字符：
圖片
我們可以自定義一個轉義注解，打上該注解的字段，表示需要轉義。
有個專門的AOP攔截器，將用戶的原始內容，轉換成轉義后的內容。
保存到數據庫中是轉義之后的內容。
除此之外，為了防止SQL注入的情況，也需要將用戶輸入的參數做SQL語句方面的轉義。
關于SQL注入問題，可以參考我之前寫的這篇文章：臥槽，sql注入竟然把我們的系統搞掛了
4 做權限控制
我們需要對接口做權限控制。
主要包含了下面3種情況。
4.1 校驗是否登錄
對于用些公共數據，比如：外部分類，所有人都能夠看到，不用登錄也能看到。
對于這種接口，則不用校驗登錄。
而對于有些查看內部分類的接口，需要用戶登錄之后，才能訪問。
這種情況就需要校驗登錄了。
可以從當前用戶上下文中獲取用戶信息，校驗用戶是否登錄。
如果用戶登錄了，當前用戶上下文中該用戶的信息不為空。
否則，如果用戶沒登錄，則當前用戶上下文中該用戶的信息為空。
4.2 接口功能權限控制
對于有些重要的接口，比如訂單審核接口，只有擁有訂單審核權限的運營賬號，才有權限訪問該接口。
我們需要對該接口做功能權限控制。
可以自定義一個權限注解，在注解上可以添加權限點。
在網關層有個攔截器，會根據當前請求的用戶的權限，去跟請求的接口的權限做匹配，只有匹配上次允許訪問該接口。
4.3 接口數據權限控制
對于有些訂單查詢接口，普通運營只能查看普通用戶的數據。
而運營經理可以查看普通用戶和vip用戶的數據。
這種情況我們需要對該訂單查詢接口做數據權限控制。
不同的角色，能夠查看的數據范圍不同。
可以在查詢數據時，在sql語句中動態拼接過濾數據權限的sql。
5 加驗證碼
對于一些非常重要的接口，在做接口設計的時候，要考慮惡意用戶刷接口的情況。
最早的用戶注冊接口，是需要用圖形驗證碼校驗的，比如下面這樣的：
圖片
用戶只需要輸入：賬號名稱、密碼和驗證碼即可，完成注冊。
其中賬號名稱作為用戶的唯一標識。
但有些圖形驗證碼比較簡單，很容易被一些暴力破解工具破解。
由此，要給圖形驗證碼增加難道，增加一些干擾項，增加暴力破解工具的難道。
但有個問題是：如果圖形驗證碼太復雜了，會對正常用戶使用造成一點的困擾，增加了用戶注冊的成本，讓用戶注冊功能的效果會大打折扣。
因此，僅靠圖形驗證碼，防止用戶注冊接口被刷，難道太大了。
后來，又出現了一種移動滑塊形式的圖形驗證方式，安全性更高。
圖片
此外，使用驗證碼比較多的地方是發手機短信的功能。
發手機短信的功能，一般是購買的云服務廠商的短信服務，按次收費，比如：發一條短信0.1元。
如果發送短信的接口，不做限制，被用戶惡意調用，可能會產生非常昂貴的費用。
6 限流
上一節中提到的發送短信接口，只校驗驗證碼還不夠，還需要對用戶請求做限流。
從頁面上的驗證碼，只能限制當前頁面的不能重復發短信，但如果用戶刷新了頁面，也可以重新發短信。
因此非常有必要在服務端，即：發送短信接口做限制。
我們可以增加一張短信發送表。
該表包含：id、短信類型、短信內容、手機號、發送時間等字段。
圖片
有用戶發送短信請求過來時：
- 先查詢該手機號最近一次發送短信的記錄
- 如果沒有發送過，則發送短信。
- 如果該手機號已經發送過短信，但發送時間跟當前時間比超過了60秒，則重新發送一條新的短信。
- 如果發送時間跟當前時間比沒超過60秒，則直接提示用戶操作太頻繁，請稍后重試。
這樣就能非常有效的防止惡意用戶刷短信的行為。
但還是有漏洞。
比如：用戶知道在60秒以內，是沒法重復發短信的。他有個程序，剛好每隔60秒發一條短信。
這樣1個手機號在一天內可以發：60*24 = 1440 條短信。
如果他有100個手機號，那么一天也可以刷你很多條短信。
由此，還需要限制每天同一個手機號可以發的短信次數。
其實可以用redis來做。
用戶發短信之后，在redis中保存一條記錄，key是手機號，value是發短信的次數，過期時間是24小時。
這樣在發送短信之前，要先查詢一下，當天發送短信的次數是否超過10次（假設同一個手機號一天最多允許發10條短信）。
如果超過10次，則直接提示用戶操作太頻繁，請稍后重試。
如果沒超過10次，則發送短信，并且把redis中該手機號對應的value值加1。
短信發送接口完整的校驗流程如下：
圖片
7 加ip白名單
對于有些非常重要的基礎性的接口，比如：會員系統的開通會員接口，業務系統可能會調用該接口開通會員。
會員系統為了安全性考慮，在設計開通會員接口的時候，可能會加一個ip白名單，對非法的服務器請求進行攔截。
這個ip白名單前期可以做成一個Apollo配置，可以動態生效。
如果后期ip數量多了的話，可以直接保存到數據庫。
只有ip在白名單中的那些服務器，才允許調用開通會員接口。
這樣即使開通會員接口地址和請求參數被泄露了，調用者的ip不在白名單上，請求開通會員接口會直接失敗。
除非調用者登錄到了某一個白名單ip的對應的服務器，這種情況極少，因為一般運維會設置對訪問器訪問的防火墻。
當然如果用了Fegin這種走內部域名的方式訪問接口，可以不用設置ip白名單，內部域名只有在公司的內部服務器之間訪問，外面的用戶根本訪問不了。
但對于一些第三方平臺的接口，他們更多的是通過設置ip白名單的方式保證接口的安全性。
8 校驗敏感詞
對于某些用戶可以自定義內容的接口，還需要對用戶輸入的內容做敏感詞校驗。
比如：在創建商品頁面，用戶輸入了：傻逼商品，結果直接顯示到了商城的商品列表頁面，這種情況肯定是不被允許的。
當然你也可以做一個審核功能，對用戶創建的商品信息做人工審核，如果商品數量太多，這樣會浪費很多人力。
有個比較好的做法是：對用戶自定義的內容，做敏感詞校驗。
可以調用第三方平臺的接口，也可以自己實現一個敏感詞校驗接口。
可以在GitHub上下載一個開源的敏感詞庫，將那些敏感詞導入到數據庫中。
然后使用hanlp對用戶輸入的內容，進行分詞。對分好的詞，去匹配敏感詞庫中的那些敏感詞。
如果匹配上了，則說明是敏感詞，則驗證不通過。
如果沒有匹配上，則說明非敏感詞，則驗證通過。
不可能在每個業務接口中都調用敏感詞校驗接口，我們可以自定義注解，在AOP攔截器中調用敏感詞校驗接口。
在調用業務接口之前，先觸發攔截器，校驗打了敏感詞校驗注解的那些字段，將他們里面包含的內容，作為入參傳入敏感詞校驗接口做校驗。
當然有時候hanlp分詞器會把句子分錯詞，還需要添加一個敏感詞的白名單，白名單中的詞不是敏感詞。
9 使用https協議
以前很多接口使用的是HTTP（HyperText Transport Protocol，即超文本傳輸協議）協議，它用于傳輸客戶端和服務器端的數據。
雖說HTTP使用很簡單也很方便，但卻存在以下3個致命問題：
- 使用明文通訊，內容容易被竊聽。
- 不驗證通訊方的真實身份，容易遭到偽裝。
- 無法證明報文的完整性，報文很容易被篡改。
為了解決HTTP協議的這些問題，出現了HTTPS協議。
HTTPS協議是在HTTP協議的基礎上，添加了加密機制：
- SSL：它是Secure Socket Layer的縮寫， 表示安全套接層。
- TLS：它是Transport Layer Security的縮寫，表示傳輸層安全。
HTTPS = HTTP + 加密 + 認證 + 完整性保護。
為了安全性考慮，我們的接口如果能使用HTTPS協議，盡量少使用HTTP協議。
如果你訪問過一些大廠的網站，會發現他們提供的接口，都是使用的HTTPS協議。
不過需要注意的地方是：HTTPS協議需要申請證書，有些額外的費用。
10 數據加密
有些信息是用戶的核心信息，比如：手機號、郵箱、密碼、身份證、銀行卡號等，不能別泄露出去。
在保存到數據庫時，我們要將這些字段，做加密處理。
后面即使這些數據被泄露了，獲得數據的人，由于沒有密鑰，沒辦法解密。
這種情況可以使用AES對稱加密的方式，因為后面系統的有些業務場景，需要把加密的數據解密出來。
為了安全性考慮，我們需要設置一個用于加密的密鑰，這個密鑰可以稍微復雜一點，包含一些數字、字母和特殊字符。
我們同樣可以通過自定義注解的方式，給需要加密的字段添加該注解，在Mybatis攔截器中實現加解密的功能。
對于查詢操作，需要將加了該注解的字段的數據做解密處理。
對于寫入操作，要將加了該注解的字段的數據做加密處理。
有些頁面顯示的地方，手機號一般不會顯示完整的手機號，中間有一部分用*代替，比如：182***3457。
這種情況需要做特殊處理。
11 做風險控制
有些特殊的接口，比如用戶登錄接口，我們需要對該接口做風險控制，盡可能減小被盜號的風險。
用戶登錄失敗之后，需要有地方，比如：Redis，記錄用戶登錄失敗的次數。
如果用戶第一次輸入賬號密碼登錄時，出現的是一個稍微簡單的驗證碼。
如果用戶把賬號或密碼連續輸錯3次之后，出現了更復雜的驗證碼。
或者改成使用手機短信驗證。
如果用戶在一天之內，把賬號或密碼連續輸錯10次，則直接鎖定該賬號。
這樣處理是為了防止有人用一些軟件，暴力破解賬號和密碼。
在用戶登錄成功之后，需要有一張表記錄用戶的ip、所在城市和登錄的設備id。
如果你的賬號被盜了。
在盜號者在頁面輸入賬號密碼登錄，會調用登錄接口，此時登錄接口中可以根據用戶的ip和設備id，做一些風險控制。
接口判斷如果用戶當前登錄的ip、所在城市和設備ip，跟上一次登錄成功時記錄的相差非常大。
比如：1小時之前，用的ip是100.101.101.101，城市是北京，設備id是1001，而1小時之后，用的ip是200.202.202.101，城市是廣州，設備id是2002。
這種情況用戶的賬號極有可能被盜了。
登錄接口做安全性升級，需要校驗用戶手機驗證碼才能登錄成功。
由于盜號者只有你的賬號和密碼，沒有手機驗證碼，所以即使被盜號了，也沒辦法登錄成功。
