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