接口敏感數據被竊取

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

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

注：某單位在某省攻防演練，一下扣到負幾千分的原因，您找到了嗎？需要防護改進，請聯系三沐，必須給你安排的明明白白。

XSS 攻擊

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

系統層面的安全防護解決措施

在系統架構設計之初，系統安全一定是一個重要的考量因素被納入到架構設計規劃中，系統安全關乎著既關乎公司的生存，也關乎產品的盈利，更進一步說，更關乎著法律法規對公司的監管合規性依據。下圖所示，為一個通用的微服務業務架構圖。

從實踐經驗來看，安全在一個系統的架構設計中占據著舉足輕重的地位，從上圖來看，可以說，安全考慮在架構設計的每一環都有著落地的目標，拆開來看，具體如下所述。

前端安全

涉及到前端安全的技術，比如：

· 頁面表單的防重提交（功能上限制防刷的可能性）；

· 接口請求前關鍵參數的校驗，脫敏，XSS 不安全字符的自動識別；

· 使用參數加密，Base64 處理，禁止明文傳輸;

系統級防火墻

防火墻本身具有較強的抗攻擊能力，它是提供信息安全服務、實現網絡和信息安全的基礎設施之一。

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

關于防火墻的作用，這里簡單列舉如下：

·防止來自被保護區域外部的攻擊，保護易受攻擊的網絡服務資源和客戶資源；

·集中安全管理，通過集中的安全策略配置，以便統一管理和執行安全政策；

·防止信息外泄和屏蔽有害信息，執行安全檢查，嚴格控制進出網絡的數據，過濾和屏蔽有害信息，防止信息外泄；

·安全審計和告警，通過對網絡存取訪問進行監控審計，有效跟蹤各類網絡活動，及時發現問題和及時報警。

網關

關于網關，基本上所有的人都多少有一定的了解，網關在一個安全的系統架構設計中的作用，可以說是承上啟下，至關重要，大體來說，從安全的角度來講，主要體現在如下幾個方面：

屏蔽真實的API地址

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

負載均衡，均衡流量

從系統安全和系統可用性的角度講，為了確保系統的高可用性，通常應用服務集群部署，這樣可以避免單節點壓力過大而造成業務高峰時系統不可用，有了網關這一層，就可以通過網關的配置動態實現負載均衡，以達到均衡流量的效果，從而對系統過載形成防護。

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

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

限流

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

API 安全設計的常用解決方案

在討論了架構設計中的安全防護措施后，作為系統對外提供數據來源的核心后臺服務的 API 接口，關于 API 的安全考慮，許多開發者在設計過程中尚未引起足夠的重視。以下是小編分享的一個有趣現象：在過去的工作經歷中，甲方公司在項目驗收時，通常會對整個源碼進行安全審計，其中 API 接口的安全問題，如 XSS 攻擊、CSRF 攻擊和接口被刷的風險，常常是審計中最容易出問題的部分。

接下來，我們將探討針對這些問題以及日常開發中API 安全的一些規范性要求。

控制 API 的訪問邊界

在當前流行的微服務架構中，后臺 API 的訪問邊界必須規范：

• 接口設計之初，與前端開發者約定接口的使用場景。
• 對外暴露的無需鑒權接口，需要做好流量控制（流控），防止被刷，如登錄接口中使用短信驗證碼的場景。
• 無需鑒權的對外接口，應進行嚴格的參數校驗，防止 XSS 字符存儲。
• 需要鑒權的接口，最好采用統一的安全校驗邏輯，如使用 SDK 或內部封裝的組件。

嚴格規范 API 的使用類型

針對大平臺，如 PaaS 平臺，其由多個內部服務組成，這些服務之間的調用（如 Dubbo 或 HTTP 調用）需要規范：

• 系統外部可調用的 API：需要通過統一的憑證頒發入口，調用者通過憑證驗證后才能獲取響應，憑證可設有效期或加密。
• 系統內部可調用的 API：內部應用間調用時，通過添加如 appName 這樣的標識進行認證。
• 無需認證的 API：如首頁請求或獲取短信驗證碼，應做好參數校驗、防刷處理及可信 IP 識別。

API 敏感參數加密處理

對于登錄、獲取用戶信息等接口，需加密處理以防會話劫持：

• 密碼的 MD5 加密（可加鹽提高安全性）。
• 對稱或非對稱加密，根據業務需要選擇。
• 使用 JWT 進行輕量級的加解密。

API 請求 header 中混合特殊參數

前端請求時，在 header 中添加 token 等參數，進行統一校驗。更高級的安全可以混合定制化參數。

API 自身的防刷措施

即使有統一的防護措施，對核心業務 API 仍需額外防刷：

• 通過 IP 和業務關鍵字段組合識別惡意請求，限制頻次。
• 使用限流組件或 SDK 對熱點 API 進行流量控制。
• 日志跟蹤并接入告警系統，監控惡意請求。

盡量對請求參數進行封裝

從安全角度，POST 請求比 GET 請求安全，建議當查詢參數超過5個時，封裝參數并使用 POST 請求。

API 參數校驗

雖然是基礎，但參數校驗是 API 安全的最后保障：

• 區分 API 的重要程度：不是所有 API 都需要復雜的參數校驗，特別是涉及數據保存、修改或刪除的接口。
• 不要過度校驗：在某些接口中，過多的參數校驗可能不是必要的，應根據實際需求來決定校驗的程度。

推薦閱讀

API是什么
API安全是什么
如何評估API 安全性
如何實施API 安全策略
7 大 REST API 安全威脅