一、前言

伴隨著移動互聯(lián)網(wǎng)時代的飛速發(fā)展，人手一部智能機連接這個世界已經(jīng)成為現(xiàn)狀，隱私和安全問題也逐漸被越來越多的人重視。從 2021 年某滴安全信息泄露的消息公之于眾后，人們對于信息安全的呼聲和訴求也越發(fā)高漲。

我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、祿勸ssl等。為上1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的祿勸網(wǎng)站制作公司

回到正題，不管是 app，還是各個訪問終端的入口，作為最終承載交互數(shù)據(jù)的來源 — API 接口，無疑需要對數(shù)據(jù)的安全訪問提供最終的支撐和保障。接下來，讓我們花點時間來聊聊關(guān)于 API 接口安全的那些事吧。

二、API 安全常見問題

經(jīng)常聽人說，某某系統(tǒng)被黑了，某某 app 的短信 1 分鐘內(nèi)被狂刷了幾萬條，某某應(yīng)用的系統(tǒng)癱瘓了...諸如此類不一而足。追根溯源，從問題分析的經(jīng)驗來看，不管系統(tǒng)攻擊者采用何種手段，多數(shù)情況下，最終攻擊的入口，或者說最終的受害者還是匯聚到了API 這一層，可見，API 可以說是系統(tǒng)的守衛(wèi)員，不容有失。

關(guān)于 API 的常見安全問題有哪些呢？小編這里結(jié)合多年的實踐經(jīng)驗，做了如下的一些總結(jié)以供參考。

1、接口被惡意調(diào)用

當(dāng)系統(tǒng)的某些接口被攻擊者或別有用心的人惡意調(diào)用時，可能有如下表現(xiàn)：

• 系統(tǒng)被狂刷短信...
• 某個頁面直接卡死，導(dǎo)致其他用戶無法訪問頁面...
• 系統(tǒng)服務(wù)器 CPU 瞬間飆升...
• 平臺內(nèi)關(guān)聯(lián)的其他應(yīng)用也無法正常使用...

為什么 API 接口會被惡意調(diào)用呢？經(jīng)驗來看，無非就那點，樹大招風(fēng)，你的產(chǎn)品被競爭對手盯上了，人家眼紅了。

2、接口數(shù)據(jù)被篡改

這也是一種比較場景的 API 安全問題，一個常見的場景就是，當(dāng)你登錄某個系統(tǒng)時，你的會話信息，像存在瀏覽器中的 cookie 信息，被別有用心者劫持了，然后這個人拿著你的信息冒充你的身份去請求 API 的數(shù)據(jù)，甚至修改你的數(shù)據(jù)返回給你進(jìn)行詐騙等目的。使用過 Fiddler 抓包工具的同學(xué)可以在自己公司的產(chǎn)品中模擬下這個過程。

3、接口敏感數(shù)據(jù)被竊取

通常在 B 端產(chǎn)品中，會對某些 API 返回的部分字段數(shù)據(jù)進(jìn)行脫敏，比如手機號，郵箱等，以保證用戶的信息隱私。

盡管 API 層面對敏感數(shù)據(jù)做了脫敏處理，但敏感數(shù)據(jù)如果未進(jìn)行加密處理，或加密的強度不夠，或者沒有安全的存儲加密數(shù)據(jù)，以至于攻擊者仍然能夠獲得敏感信息，進(jìn)而攻擊者可能利用此漏洞對客戶端，或服務(wù)器發(fā)送特殊構(gòu)造的數(shù)據(jù)，發(fā)出攻擊，從而了解后臺數(shù)據(jù)庫表等信息，對系統(tǒng)安全構(gòu)成威脅。這也就是接口敏感數(shù)據(jù)被竊取了。

4、XSS 攻擊

深究起來，XSS 攻擊更多偏向于前端這一層，但是對于一個能夠提供充分安全保障的系統(tǒng)來說，API 的對于參數(shù)的安全校驗也是非常重要的一環(huán)，對于系統(tǒng)來說，應(yīng)該確保核心 API 的業(yè)務(wù)對于所有的入?yún)⒍紤?yīng)該是安全，可信且經(jīng)過校驗之后才能進(jìn)行數(shù)據(jù)存儲的。這樣可以從源頭上保障 XSS 攻擊影響的范圍進(jìn)一步縮小。

三、系統(tǒng)層面的安全防護(hù)解決措施

在系統(tǒng)架構(gòu)設(shè)計之初，系統(tǒng)安全一定是一個重要的考量因素被納入到架構(gòu)設(shè)計規(guī)劃中，系統(tǒng)安全關(guān)乎著既關(guān)乎公司的生存，也關(guān)乎產(chǎn)品的盈利，更進(jìn)一步說，更關(guān)乎著法律法規(guī)對公司的監(jiān)管合規(guī)性依據(jù)。下圖所示，為一個通用的微服務(wù)業(yè)務(wù)架構(gòu)圖。

從實踐經(jīng)驗來看，安全在一個系統(tǒng)的架構(gòu)設(shè)計中占據(jù)著舉足輕重的地位，從上圖來看，可以說，安全考慮在架構(gòu)設(shè)計的每一環(huán)都有著落地的目標(biāo)，拆開來看，具體如下所述。

1、前端安全

涉及到前端安全的技術(shù)，比如：

• 頁面表單的防重提交（功能上限制防刷的可能性）。
• 接口請求前關(guān)鍵參數(shù)的校驗，脫敏，XSS 不安全字符的自動識別。
• 使用參數(shù)加密，Base64 處理，禁止明文傳輸。

2、系統(tǒng)級防火墻

防火墻本身具有較強的抗攻擊能力，它是提供信息安全服務(wù)、實現(xiàn)網(wǎng)絡(luò)和信息安全的基礎(chǔ)設(shè)施之一。

防火墻對于一個互聯(lián)網(wǎng)公司的重要意義毋庸置疑，尤其是金融類，銀行類等 B 端產(chǎn)品，防火墻的作用可以說是不可替代的，盡管這個技術(shù)已經(jīng)不是什么新鮮的東西，但基本上所有的軟件公司在產(chǎn)品發(fā)布到線上環(huán)境之后，所有來自外部的請求，都會經(jīng)過服務(wù)器廠商的防火墻，只有通過了防火墻這一層請求才能繼續(xù)往下進(jìn)行。

關(guān)于防火墻的作用，這里簡單列舉如下：

• 防止來自被保護(hù)區(qū)域外部的攻擊，保護(hù)易受攻擊的網(wǎng)絡(luò)服務(wù)資源和客戶資源；
• 集中安全管理，通過集中的安全策略配置，以便統(tǒng)一管理和執(zhí)行安全政策；
• 防止信息外泄和屏蔽有害信息，執(zhí)行安全檢查，嚴(yán)格控制進(jìn)出網(wǎng)絡(luò)的數(shù)據(jù)，過濾和屏蔽有害信息，防止信息外泄；
• 安全審計和告警，通過對網(wǎng)絡(luò)存取訪問進(jìn)行監(jiān)控審計，有效跟蹤各類網(wǎng)絡(luò)活動，及時發(fā)現(xiàn)問題和及時報警。

3、網(wǎng)關(guān)

關(guān)于網(wǎng)關(guān)，基本上所有的人都多少有一定的了解，網(wǎng)關(guān)在一個安全的系統(tǒng)架構(gòu)設(shè)計中的作用，可以說是承上啟下，至關(guān)重要，大體來說，從安全的角度來講，主要體現(xiàn)在如下幾個方面：

屏蔽真實的API地址

拿 nginx 來說，如果后端的接口真實地址是：/API/v2/user/get/1，為了確保接口安全，屏蔽真實的地址，通過nginx 的反向代理之后，接口可能變成這樣：
/platform/biz/API/v2/user/get/1。

負(fù)載均衡，均衡流量

從系統(tǒng)安全和系統(tǒng)可用性的角度講，為了確保系統(tǒng)的高可用性，通常應(yīng)用服務(wù)集群部署，這樣可以避免單節(jié)點壓力過大而造成業(yè)務(wù)高峰時系統(tǒng)不可用，有了網(wǎng)關(guān)這一層，就可以通過網(wǎng)關(guān)的配置動態(tài)實現(xiàn)負(fù)載均衡，以達(dá)到均衡流量的效果，從而對系統(tǒng)過載形成防護(hù)。

攔截惡意請求，定向黑白名單

以 nginx 來說，提供了可編程式的配置，通過編寫腳本代碼，對經(jīng)過 nginx 的請求進(jìn)行監(jiān)控，尤其是對于那些惡意刷接口的請求，可以很好的進(jìn)行識別，甚至可以在 nginx 這一層對那些惡意請求的 IP，IP 段進(jìn)行黑名單的設(shè)置，從而對后臺的服務(wù)進(jìn)行第一層的安全防護(hù)。

限流

對一個系統(tǒng)來說，可用性已然成了系統(tǒng)是否穩(wěn)定的考量因素的重要標(biāo)準(zhǔn)，當(dāng)業(yè)務(wù)高峰期時，不管是外部的惡意請求，還是類似搶單這樣的瞬間大流量來說，為了保障系統(tǒng)的整體可用性，必要的限流措施也是確保系統(tǒng)安全的重要手段，而網(wǎng)關(guān)作為承載系統(tǒng)流量的入口，在網(wǎng)關(guān)這一層做一定的限流管控是很有必要的。

四、API 層面安全設(shè)計的常用解決方案

以上從架構(gòu)設(shè)計層面聊了一下常用的安全防護(hù)措施，而作為系統(tǒng)對外提供數(shù)據(jù)來源的 API 接口，也就是系統(tǒng)的核心后臺服務(wù)，可以說，關(guān)于 API 的安全考慮，可以說很多開發(fā)者在設(shè)計過程中尚未引起足夠的重視。這里小編說一個有意思的現(xiàn)象，在小編過往的工作經(jīng)歷中，那些甲方公司最終對項目進(jìn)行驗收時，通常需要對整個源碼進(jìn)行安全審計，其中審計最容易出問題的地方，就是很多 API 接口的安全問題，比如 XSS 攻擊，CSRF 攻擊，接口有被刷的風(fēng)險...

接下來，針對上述談到的問題，以及日常開發(fā)中對于 API 安全的一些規(guī)范性要求，一起探討下在 API 安全設(shè)計的一些處理措施。

1、控制 API 的訪問邊界

以當(dāng)下流行的微服務(wù)來說，后臺提供出去的 API 一定要規(guī)范訪問邊界，哪些接口可以暴露出去，哪些接口一定要通過鑒權(quán)才能訪問，關(guān)于這一點，依照經(jīng)驗來說，做好下面幾點即可：

• 接口設(shè)計之初，與前端同學(xué)約定好接口的使用場景；
• 對外暴露且不需要鑒權(quán)的接口做好流控，避免被刷，比如有些登錄接口中需要用到短信驗證碼的場景；
• 對外暴露且不需要鑒權(quán)的接口做好嚴(yán)格的參數(shù)校驗，避免 XSS 字符的入庫存儲；
• 需要走鑒權(quán)的接口，最好走統(tǒng)一的安全校驗邏輯，比如 SDK 或者內(nèi)部封裝的組件；

2、嚴(yán)格規(guī)范 API 的使用類型

對于某些比較大的平臺來說，比如 pass 平臺，通常都是十幾個甚至幾十上百個內(nèi)部服務(wù)組成的，如此龐大的系統(tǒng)統(tǒng)一對外提供服務(wù)時，各應(yīng)用服務(wù)之間必然存在著互相的調(diào)用，這些可以是 dubbo 調(diào)用，或者 http 的調(diào)用，通常不同的應(yīng)用之間調(diào)用時，走 rest 接口非常多，同時，不同應(yīng)用之間互相調(diào)用時，場景也是多樣，有些需要認(rèn)證，有些不需要，有些需要嚴(yán)格的認(rèn)證，有些需要寬容的認(rèn)證，這該怎么辦呢？

針對上面的場景，這里可以考慮定義不同的 API 使用類型，針對不同類型的 API，在調(diào)用的時候策略也不一樣，具體實踐來說，可以參照如下設(shè)計原則；

系統(tǒng)外部可調(diào)用的 API

這種 API，即內(nèi)部應(yīng)用和外部應(yīng)用都可以調(diào)用的 API，這類 API 的設(shè)計，通常需要通過一個統(tǒng)一的憑證頒發(fā)入口，調(diào)用者拿到這個憑證，在調(diào)用 API 時傳過去，認(rèn)證通過后，API 給與數(shù)據(jù)響應(yīng)，由于憑證是系統(tǒng)內(nèi)部的服務(wù)頒發(fā)，可以認(rèn)為是安全的，同時，如果更進(jìn)一步的話，可以對憑證做有效期的設(shè)定，甚至是加密處理等措施。

系統(tǒng)內(nèi)部可調(diào)用的 API

即平臺各個微服務(wù)應(yīng)用之間調(diào)用的 API，由于內(nèi)部的應(yīng)用在使用之前，都需要一定的注冊或者其他的認(rèn)證措施，對于內(nèi)部的 API 調(diào)用來說，可以在 API 接口中添加關(guān)鍵參數(shù)信息識別即可，比如，在請求內(nèi)部 API 的時候添加一個 appName 這樣的標(biāo)識，一旦 API 校驗這個 appName 合法有效，就可以給與響應(yīng)。

無需認(rèn)證的 API

比如請求系統(tǒng)的首頁，或者上面談到的請求短信驗證碼，再就是某些需要對接平臺的外部第三方應(yīng)用，這些第三方應(yīng)用需要拿到一些非敏感的數(shù)據(jù)作為業(yè)務(wù)標(biāo)識等，這種情況下，針對這樣的 API，在設(shè)計時，要做好關(guān)鍵參數(shù)的校驗，接口防刷的處理，以及可信 IP 的識別。

3、API 敏感參數(shù)加密處理

類似于登錄，獲取用戶信息的 API 接口，一定要做加密處理，防止因會話劫持造成數(shù)據(jù)傳輸過程中敏感信息的泄露，關(guān)于加密，常用的加密方式包括：

• 密碼的 MD5 加密，甚至可以混合鹽值提高加密的安全等級。
• 對稱或非對稱加密（根據(jù)業(yè)務(wù)需要選擇）。
• JWT，也是當(dāng)下流行的一種輕量化的加解密方案。

4、API 請求 header 中混合特殊參數(shù)

一種常見的場景就是，前端請求 API 接口時，需要在請求的 header 中添加后臺辦法的 token 或者其他的令牌等參數(shù)，而請求到達(dá) API 之前（有的在 API 中做），解析并統(tǒng)一校驗 API 請求中的 header 是否攜帶了這個參數(shù)，且有效的情況下才予以返回。如果你的 API 安全等級更高，可以考慮在請求 header 中混合其他的定制化參數(shù)，這也是一種有效的保護(hù) API 的手段。

5、API 自身的防刷措施

對于一個成熟穩(wěn)定的系統(tǒng)來說，盡管請求在真正到達(dá) API 時有各種防護(hù)措施，比如限流，惡意請求 IP 識別等統(tǒng)一的措施，但是作為打通數(shù)據(jù)后臺到前臺的最后一關(guān)，針對系統(tǒng)中的某些核心業(yè)務(wù)的 API，還是有必要做針對性的接口防刷機制，具體來說，可參考下面的思路進(jìn)行實施。

• 根據(jù)來源 IP，核心業(yè)務(wù)字段的組合進(jìn)行惡意請求的識別，限制這類請求頻次，減少對服務(wù)端的壓力。
• API 采用限流組件，或者引入開源限流 SDK，或者自己編寫限流算法工具包，對熱點 API 進(jìn)行限流。
• 日志追蹤，針對那些惡意刷接口的 IP，記錄在日志，并接入告警平臺，定向的上報監(jiān)控告警。

6、盡量對請求參數(shù)進(jìn)行封裝

一般來說，從 rest 請求安全的角度來說，post 請求的安全性要好于 get 請求，這是因為大多數(shù)情況下，get 請求暴露在請求 url 中，而 post 請求的參數(shù)相對來說會隱蔽一些。這里給出的建議是，當(dāng)查詢請求參數(shù)超過 5 個時，可以對請求參數(shù)進(jìn)行封裝，然后將親請求類型調(diào)整為 post。

7、API 參數(shù)校驗

為什么這一點放在最后來說，小編認(rèn)為這是大多數(shù)開發(fā)者能夠想到但在實際工作中又不能做得很好的一點。參數(shù)校驗可以說是 API 層面最后一道基礎(chǔ)但是重要的安全保障了，但是在參數(shù)校驗這個度的把握上，很多開發(fā)人員顯得有些不知所措，這里小編提出下面幾點建議以供參考：

區(qū)分 API 的重要程度

并不是所有的 API 都需要一大堆的參數(shù)校驗，為什么這么說呢？要知道，參數(shù)對于一個系統(tǒng)安全的影響隨著鏈路的傳遞是逐漸增加的，假如說一段xss的字符作為參數(shù)傳入到 API 接口中，假如不做處理最終會入庫，后面再查詢出來渲染到頁面時候，這個危害性就大了，影響的不僅是用戶的體驗，甚至?xí)ヒ粋€潛在的有價值的用戶。

說到這里，相信大家能夠了解，假如在 save 數(shù)據(jù)的接口中就能夠識別非法參數(shù)，從而進(jìn)行攔截的話，后續(xù)所有的麻煩都可以提前避免掉。從這個角度來說，一個通用的做法就是，針對那些需要保存表單的數(shù)據(jù)，或者是涉及到修改，刪除之類的 API，一定要做好參數(shù)的校驗和控制。

不要過度對參數(shù)進(jìn)行校驗

看到過不少開發(fā)者在一個存儲數(shù)據(jù)的接口中對參數(shù)進(jìn)行了相當(dāng)篇幅的代碼校驗，并不是說這樣不好，而是需要區(qū)分一個度的問題，舉例來說，有人在編寫一個保存用戶的 API 接口時，對用戶名稱做校驗時，大概有幾十行代碼，涉及的規(guī)則如下：

• 校驗賬戶中是否有特殊字符，比如 $% 這樣的字符。
• 校驗賬戶名稱長度是否超過限制。
• 校驗系統(tǒng)中是否有重復(fù)的賬戶名。
• 校驗賬戶名中是否有違禁的詞。
• 校驗賬戶名中是否有多音字。
• ...

我就想不通了，一個賬戶名的校驗需要搞那么多花樣嗎，開個玩笑，這當(dāng)然不是我的過激行為，我要表達(dá)的意思是，API 設(shè)計時，在考慮安全性的同時盡可能兼顧使用者的習(xí)慣，簡化因參數(shù)校驗帶來的交互流程上的麻煩。

五、寫在文末

安全無小事，這句話應(yīng)該來說對所有的行業(yè)都適用。希望從事開發(fā)的伙伴們在日常開發(fā)中對系統(tǒng)安全多一份敬畏，從而少一些因安全事故帶來的不必要的麻煩。當(dāng)然，系統(tǒng)的安全性建設(shè)是一項長期的工作，需要自頂而下，做好長遠(yuǎn)的規(guī)劃，并逐步落實并貫穿到日常的每一個開發(fā)、測試、運維以及實施過程中，這樣這才是長久之計，與君共勉。

網(wǎng)頁題目：關(guān)于接口API安全你需要知道的那些事
當(dāng)前URL：http://uogjgqi.cn/article/dhjesii.html