文章目錄

• API安全風險與防范
• • 前言
  • API安全風險與防范
  • • 未授權訪問
    • 越權問題
    • 數據竊聽
    • DDoS攻擊
    • 資源耗盡攻擊
    • 重放攻擊（Replay Attack）
    • 注入攻擊
    • 篡改數據
    • 代碼泄漏
    • 數據泄漏
    • API URL泄漏
    • 服務端被黑
  • 攻擊者的常用手段
  • API安全小結
  • 安全三要素
  • 參考文檔
  • 擴展閱讀

API安全風險與防范

前言

本文就API安全面臨的常見風險和如何防范，淺談了一下個人見解，供API設計和開發時參考。

API安全風險與防范

未授權訪問

風險：攻擊者知道API地址和傳入參數后，訪問未授權的數據或操作。

防范：

前端調用后端的接口，必須由后端作二次校驗，不能只相信前端頁面控制；

系統對系統的接口，需要用身份認證機制（比如，appId和appSecret機制、token機制）

參見：

• 移動應用微信登錄開發指南

越權問題

風險：攻擊者試圖訪問權限范圍外（水平越權或垂直越權）的數據或操作。

防范：

不信任接口調用傳入參數，必須由后端對訪問作嚴格的權限控制，不要偷懶；

前端調用后端的接口，必須由后端作二次校驗，不能只相信前端頁面控制；

不相信前端傳進來的和權限有關的參數（或者不要讓前端傳進來和權限有關的參數），而是后端自動獲取當前登錄用戶的權限相關的信息；

后端不能只判斷用戶是否登錄，而是還要判斷當前用戶是否有權限；

特別小心傳入id來查詢或操作的場景，一定要校驗當前用戶是否有該id的權限；

參見：

• Web業務安全測試方法（1）—越權測試

數據竊聽

風險：在調用API的傳輸過程中，數據可能會被竊聽，比如惡意WIFI、DNS劫持、網絡設備被黑等。

防范：

盡量在安全的網絡中傳輸，比如內網、專線等；

采用HTTPS協議對傳輸過程加密；

對傳輸的數據進行加密。

DDoS攻擊

風險：攻擊者控制一群肉雞，發起DDoS攻擊（分布式拒絕服務攻擊），導致接口被網絡請求堵塞，無法正常服務。

防范：

采用WAF和防火墻；

采用流量清洗和黑洞技術；

設置IP白名單；

對接口調用頻率和調用次數進行限制。

資源耗盡攻擊

風險：攻擊者利用接口漏洞來耗盡服務端資源。

防范：

限制上傳文件類型和文件大小；

限制分頁查詢時每頁的最大記錄數；

限制接口調用頻率和調用次數；

限制其它可能耗盡服務端資源的行為。

重放攻擊（Replay Attack）

風險：攻擊者獲取一段報文后，重復多次請求接口。

防范：

在請求報文中加入隨機數（nonce）和簽名，如果隨機數重復則服務端認為是無效請求；(該方法的不足是需要維護一張隨機數的全表記錄，如果用Redis來存儲可能會占用較大內存)

在請求報文中加入時間戳（timestamp）和簽名，如果請求報文的時間戳與服務端的時間差較大（比如1分鐘），則認為是無效請求；（該方法的不足是在允許的時間差內，仍然有被重放攻擊的風險）

結合nonce和timestamp機制（只在允許的時間差內維護隨機數的全表記錄，比如在Redis中隨機數全表記錄有效期只保留1分鐘，這樣就可以節約內存）；

一次性token機制，token使用一次后就失效。

參見：

• 防止重放機制
• https://www.kaspersky.com/resource-center/definitions/replay-attack

注入攻擊

風險：攻擊者傳入一些畸形數據，讓接口執行一些意想不到的操作。

防范：

程序和數據分離，不允許調用者來控制如何執行程序；

使用預編譯SQL，而不是動態拼接SQL；

在接口入參對象中只放必要的屬性，且操作時只修改必要的屬性。（防止利用JSON字符串和Object自動綁定特性，來傳入多余的JSON屬性，來更新整個對象）。

篡改數據

風險：攻擊者獲得一段報文后，篡改報文中的內容，再請求接口。

防范：

采用API簽名（sign）方式來防止數據被篡改；

客戶端對請求報文進行簽名，服務端驗簽通過后，才響應請求；

服務端對響應報文進行簽名，客戶端驗簽通過后，才相信響應報文；

常用的簽名算法包括SHA256或MD5，推薦使用SHA256（哈希算法，簽名不可逆計算出原始值）；

簽名時需要同時考慮防止簽名被預測和重放攻擊，需要將nonce和timestamp一起簽名，保證每次簽名（sign）值都不同；

參見：

• 微信支付-小程序支付安全規范

代碼泄漏

風險：代碼或程序中含有敏感信息，當代碼或程序泄漏后，敏感信息也被泄漏。

防范：

不要在前端代碼中存放secret等敏感信息，即使已經加密過的secret；

正確配置.gitignore，不要將一些不應該提交的代碼或配置文件放到了Web服務器上，特別是前端代碼；

代碼中含有一些測試用的管理用的“秘密”API URL；

代碼中含有一些過時且保護不當的API URL；

防止泄漏代碼到互聯網上，比如GitHub；

在后端服務器上，在受控的服務配置中心來配置敏感信息；

數據泄漏

風險：接口返回了過多的數據，包括敏感數據。

防范：

只返回必要的數據給前端，不要依賴前端來隱藏數據；

由后端來對敏感數據進行脫敏，不要依賴于前端進行脫敏。

API URL泄漏

風險：使用HTTP GET調用API時，API URL上帶有參數，因為API URL是明文傳輸的，因此網絡中的網絡節點都可能竊取這些參數數據。

防范：

不要在API URL中放敏感信息；

盡量使用HTTP POST，來在HTTP Request body中傳輸參數，再采用HTTPS協議對傳輸過程加密；

服務端被黑

風險：雖然大多數攻擊都發生在客戶端向服務端的調用過程，但是如果服務端被黑，也會導致客戶端面臨風險。

防范：

做好服務端安全防范工作，最小權限原則，網絡隔離，開放最少端口，設置安全組，漏洞掃描，入侵檢測，告警等；

客戶端對服務端的返回數據也要驗簽，防止響應數據被篡改（比如攻擊者在服務端前安插了一個代理服務器來篡改返回的數據）；

攻擊者的常用手段

攻擊者的常用手段：

網絡竊聽；

抓包工具；

Chrome瀏覽器開發者工具；

編寫Python程序進行來請求接口；

病毒程序。

API安全小結

互不信任原則：接口提供方不信任接口調用方的請求參數，接口調用方不信任接口提供方的返回數據；

不信任網絡原則：假設網絡傳輸過程是不安全的，網絡中的每一個節點都是不安全的；

采用HTTPS協議，保證傳輸過程安全；

作最壞的打算，即使數據被竊聽，也無法解密；

設立網絡安全邊界，采用WAF、防火墻、網絡隔離、IP白名單、流量清洗和黑洞技術來防止DDoS攻擊；

使用API網關，在API網關上實現安全機制和限流，簡化API實現；

采用包含了nonce和timestamp的API簽名來防止數據被篡改和重放攻擊；

時刻關注水平越權問題；

注意編碼安全，防止代碼泄漏和API URL泄漏；

安全三要素

簡化的安全三要素：

• 加密（Encryption）：數據傳輸過程加密，敏感數據存儲加密。
• 認證（Authentication）：識別是誰，定義哪些是公開資源，哪些是需要用戶登錄后才能訪問的資源。
• 鑒權（Authorization）：允許或拒絕用戶的某些操作。

參考文檔

• 移動應用微信登錄開發指南
• 微信支付-小程序支付安全規范

擴展閱讀

• OWASP TOP 10
• OWASP Top 10 Web Application Security Risks

總結

以上是生活随笔為你收集整理的API安全风险与防范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。