前言

伴隨互聯(lián)網(wǎng)革命快速創(chuàng)新發(fā)展，API 需求的日益劇增，針對 API 的攻擊幾乎遍布各個行業(yè)，據(jù)報道 2022 年全年平均每月遭受攻擊的 API 數(shù)量超過 21 萬，游戲、社交、電商、制造等行業(yè)依然是攻擊者主要目標。

例如社交軟件某特，在 2021 年發(fā)生數(shù)據(jù)泄露事件，此次數(shù)據(jù)泄露影響了多達 540 萬用戶，產(chǎn)生這場“慘案” 正是攻擊者利用了登錄 API 端點，產(chǎn)生這一漏洞的原因很可能是 API 過度數(shù)據(jù)暴露以及安全配置錯誤。

顯然無論是 API 攻擊整體趨勢還是對企業(yè)和用戶的影響都是不容樂觀的。那如何去搭建 API 接口的安全“堡壘”？下面我們將展開探討。

開始前我們可以先了解下：什么是 API？深入了解 API 的概念和應(yīng)用

API 接口安全問題

API 攻擊事件頻發(fā)，其根本原因仍是 API 存在安全缺陷，隨著 API 在各個生態(tài)的快速發(fā)展，API 面臨的安全缺陷也逐漸凸顯，也引起了決策者重視，API 的安全困局也成為了現(xiàn)代IT面臨的一個共性問題。下面我舉例幾個我曾經(jīng)在開發(fā)中常遇到的 API 安全問題：

未授權(quán)訪問

這類安全問題會帶來極為嚴重的漏洞，因此小編在開發(fā)中尤為重視，API 傾向于暴露那些處理對象識別的端點，同時造成了廣泛的攻擊表層訪問控制問題。一旦遭到攻擊，攻擊者可輕易獲取到管理員的賬號密碼，并拿到系統(tǒng)的最高權(quán)限。大家可以通過白名單的方式來嚴格控制無需授權(quán)的 API 接口的訪問；除非資源完全對外開放，否則訪問默認都要授權(quán)，尤其是訪問用戶的資源或者受限制資源。

數(shù)據(jù)泄露過多

為了做到通用實現(xiàn)，一些伙伴往往傾向于公開所有對象屬性，不考慮它們各自的敏感性，而是依賴于客戶端執(zhí)行數(shù)據(jù)過濾，然后再將其顯示給用戶。在不控制客戶端狀態(tài)的情況下，服務(wù)器就會接收越來越多的過濾器，攻擊者可能會通過濫用這些過濾器，從而獲得訪問敏感數(shù)據(jù)的權(quán)限。某特引發(fā)數(shù)據(jù)泄露的一大原因，便是因為 API 端點返回了電子郵件或電話號碼等可識別數(shù)據(jù)。

安全性配置錯誤

安全配置錯誤是在日常開發(fā)中容易忽略的常見問題，不安全的默認配置、不完整或臨時配置、開放的云存儲、錯誤配置的 HTTP 標頭，不必要的 HTTP 方法、跨域資源共享（CORS）以及包含敏感信息的冗長錯誤消息都有可能引起 API 的安全問題。大家一定要注意檢測。

注入

當(dāng)不受信任的數(shù)據(jù)作為命令或查詢的一部分發(fā)送到解釋器時會發(fā)生注入缺陷，例如 SQL、NoSQL 的命令注入等。攻擊者的惡意數(shù)據(jù)可能會誘使解釋器執(zhí)行非預(yù)期的命令，或未經(jīng)授權(quán)訪問數(shù)據(jù)。

缺乏資源和速率限制

在 API 的開發(fā)中一些小伙伴，不會對客戶端/用戶可以請求的資源大小或數(shù)量施加任何限制。這不僅會影響 API 服務(wù)器的性能，從而導(dǎo)致拒絕服務(wù)（DoS），而且還為諸如暴力破解之類的身份驗證漏洞敞開了大門。我建議還是對資源和速率施加一定的限制，會讓我們更有信心保持應(yīng)用程序健康運行而良好的響應(yīng)計劃。

如何設(shè)計并保證 API 接口安全

我相信大家一般不會把大額的錢隨身攜帶。大多數(shù)人都會選擇把錢存到可信的環(huán)境中，在需要支付時采用分開的方式授權(quán)和驗證支付。API 安全防護與之相似，所以，我們需要一個具有驗證和授權(quán)策略的可信環(huán)境。接下來，我們來聊聊如何去營造這樣的一個環(huán)境。

Token 方案

大家可以將 Token 形象的理解為“身份證”，由服務(wù)端簽發(fā)與驗證，并且在有效期內(nèi)檢測是否具有合法性，根據(jù) Token 具有隨機性、不可預(yù)測性、時效性、無狀態(tài)、跨域等特點。Token 在 API 安全中發(fā)揮著重要作用，使用 Token 方案的優(yōu)點是什么？

Token 完全由應(yīng)用管理，所以它可以避開同源策略；
Token 性能高、安全性好，可以避免 CSRF 攻擊；
Token 可以是無狀態(tài)的，可以在多個服務(wù)間共享，解決跨域問題。

Token 是在服務(wù)端產(chǎn)生的。如果前端使用用戶名/密碼向服務(wù)端請求認證，服務(wù)端認證成功，那么在服務(wù)端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位。如果這個 Token 在服務(wù)端持久化（比如存入數(shù)據(jù)庫），那它就是一個永久的身份令牌。

Token 的鑒權(quán)方式：首先客戶端用戶通過用戶和密碼進行首次登錄，服務(wù)端在接收到用戶請求，驗證用戶名和密碼的正確性，登錄驗證成功后根據(jù)自定義規(guī)則生成 Token 信息，將生成的 Token 通過響應(yīng)返回給客戶端。

客戶端再將 Token 信息存儲在本地，在之后的每次請求中攜帶 Token 信息，服務(wù)端針獲取請求中的 Token，并根據(jù)定義的驗證機制判斷 Token 合法性，驗證成功獲取用戶信息，保持用戶狀態(tài)，Token 存活時間達到設(shè)置的有效期后自動失效，此后用戶請求時 Token 驗證不通過，就需要用戶重新登錄驗證。

無論是從安全的角度考慮，還是從吊銷的角度考慮，Token 都需要設(shè)有效期。使用 RefreshToken，它可以避免頻繁的讀寫操作。這種方案中，服務(wù)端無需刷新 Token 的過期時間，一旦 Token 過期，就反饋給前端，前端使用 RefreshToken 申請一個全新 Token 繼續(xù)使用。從而保障信息數(shù)據(jù)安全。

接口簽名

企業(yè)在為第三方系統(tǒng)提供接口的時候，肯定要考慮接口數(shù)據(jù)的安全問題，比如數(shù)據(jù)是否被篡改，數(shù)據(jù)是否已經(jīng)過時，請求是否唯一，數(shù)據(jù)是否可以重復(fù)提交等問題。其中數(shù)據(jù)是否被篡改相對重要。因而數(shù)據(jù)傳輸存在著極大的危險，所以必須接口簽名，接口簽名可以解決什么問題？

請求是否合法：是否是我規(guī)定的那個人；
請求是否被篡改：是否被第三方劫持并篡改參數(shù)；
防止重復(fù)請求（防重放）：是否重復(fù)請求。

請求攜帶參數(shù) Appid 和 sign，只有擁有合法的身份 appid 和正確的簽名 sign 才能放行。這樣就解決了身份驗證和參數(shù)篡改問題，即使請求參數(shù)被劫持，由于獲取不到 secret（僅作本地加密使用，不參與網(wǎng)絡(luò)傳輸），無法偽造合法的請求。措施依然不是最嚴謹?shù)模皇褂?appid 和 sign，雖然解決了請求參數(shù)被篡改的隱患，但是還存在著重復(fù)使用請求參數(shù)偽造二次請求的隱患。稱為重放攻擊（replay 攻擊），大家可以通過加入 timestamp + nonce 兩個參數(shù)來控制請求有效性，防止重放攻擊。

簡單來說一下該方案的簽名規(guī)則，首先進行線下分配 appid 和 appsecret 針對不同的調(diào)用方分配不同的 appid 和appsecret，加入 timestamp (時間戳) 2 分鐘內(nèi)數(shù)據(jù)有效，再加入流水號 nonce (防止重復(fù)提交) 至少 10 位。針對查詢接口，流水號只用于日志落地，便于后期日志核查。針對辦理類接口需校驗流水號在有效期內(nèi)的唯一性，以避免重復(fù)請求。加入 signature，所有數(shù)據(jù)的簽名信息。其中，需要放在請求頭的字段: appid、timestamp、nonce、signature。

講到這里我想大家對這兩大方案有了一定的了解，總的來說 Token+ 簽名認證兩大方案，去維護 API 安全的主要原理是：

★ 通過認證服務(wù)，提供一個認證的 WEBAPI，用戶先訪問它獲取對應(yīng)的 Token；

★ 用戶拿著相應(yīng)的 Token 以及請求的參數(shù)和服務(wù)器端提供的簽名算法計算出簽名后再去訪問指定的 API；

★ 服務(wù)器端每次接收到請求就獲取對應(yīng)用戶的 Token 和請求參數(shù)，服務(wù)器端再次計算簽名和客戶端簽名做對比，如果驗證通過則正常訪問相應(yīng)的 API，驗證失敗則返回具體的失敗信息。

當(dāng)然僅僅使用 Token+ 簽名認證兩大“根基”，去全面保障 API 安全也是較為困難的，對于我們來說，為了更好的提高 API 安全性，就需要在設(shè)計和開發(fā)階段，對 API 的安全性進行良好的構(gòu)建和設(shè)計，這就需要大家遵守 API 安全開發(fā)規(guī)范進行實施。接下來講解一下，在我開發(fā)日常中認為較為重要的五大規(guī)范。

五大安全規(guī)范

能見度

作為一名合格的應(yīng)用程序開發(fā)人員和用戶，我們需要知道正在發(fā)布哪些 API、如何以及何時更新它們、誰在訪問它們以及如何訪問它們。大家可以通過 Apifox 這類一體化協(xié)助平臺提供可視化 API 設(shè)計，及時了解用戶的 API 使用范圍，以確保 API 安全的第一步。

Bot 緩解措施

在某些環(huán)境中，大量的應(yīng)用程序流量，例如，賬戶登錄或注冊、購物車結(jié)賬是由自動化 Bot 生成的。必須了解和管理流量配置文件，包括區(qū)分好 Bot 和壞 Bot，防止自動攻擊的同時又不會阻止合法流量。有效的補充措施包括實施 Bot 白名單、黑名單和速率限制策略，以及特定于用例和相應(yīng) API 端點的地理圍欄。

訪問控制

API 訪問權(quán)限通常是不受嚴格控制的，這可能導(dǎo)致意外暴露。確保向不同用戶授予適當(dāng)?shù)?API 訪問權(quán)限是一項至關(guān)重要的安全要求，訪問者必須與企業(yè)的身份和訪問管理（IAM）系統(tǒng)進行協(xié)調(diào)。

防止漏洞利用

API 通過消除 Web 表單或移動應(yīng)用程序來簡化攻擊過程，從而使攻擊者更容易利用目標漏洞。因此，保護 API 端點免遭業(yè)務(wù)邏輯濫用和其他漏洞利用是關(guān)鍵的 API 安全緩解要求。

數(shù)據(jù)防泄漏

防止由于編程錯誤或安全控制漏洞而產(chǎn)生的 API 暴露或非授權(quán)訪問，是防止數(shù)據(jù)泄露或丟失的一項至關(guān)重要的安全要求。許多 API 攻擊都是專門為獲取對后端服務(wù)器和系統(tǒng)提供的關(guān)鍵數(shù)據(jù)的訪問而設(shè)計的。

總結(jié)

事實上 API 作為應(yīng)用程序之間，應(yīng)用與用戶之間交互的橋梁，承載著企業(yè)的業(yè)務(wù)邏輯和大量用戶數(shù)據(jù)，一旦由 API 安全漏洞引發(fā)攻擊事件，其后果注定難以承受。因此，建議企業(yè)用戶通過引用專業(yè)的 API 管理工具產(chǎn)品或解決方案，快速建立起真實、有效的 API 安全“堡壘”，通過一體化協(xié)作平臺高效，及時，準確補全安全上的缺口。