生活随笔
收集整理的這篇文章主要介紹了
API安全风险与防范
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
文章目錄
- API安全風險與防范
- 前言
- API安全風險與防范
- 未授權(quán)訪問
- 越權(quán)問題
- 數(shù)據(jù)竊聽
- DDoS攻擊
- 資源耗盡攻擊
- 重放攻擊（Replay Attack）
- 注入攻擊
- 篡改數(shù)據(jù)
- 代碼泄漏
- 數(shù)據(jù)泄漏
- API URL泄漏
- 服務端被黑
- 攻擊者的常用手段
- API安全小結(jié)
- 安全三要素
- 參考文檔
- 擴展閱讀
API安全風險與防范
前言
本文就API安全面臨的常見風險和如何防范，淺談了一下個人見解，供API設計和開發(fā)時參考。
API安全風險與防范
未授權(quán)訪問
風險：攻擊者知道API地址和傳入?yún)?shù)后，訪問未授權(quán)的數(shù)據(jù)或操作。
防范：
前端調(diào)用后端的接口，必須由后端作二次校驗，不能只相信前端頁面控制；系統(tǒng)對系統(tǒng)的接口，需要用身份認證機制（比如，appId和appSecret機制、token機制）
參見：
越權(quán)問題
風險：攻擊者試圖訪問權(quán)限范圍外（水平越權(quán)或垂直越權(quán)）的數(shù)據(jù)或操作。
防范：
不信任接口調(diào)用傳入?yún)?shù)，必須由后端對訪問作嚴格的權(quán)限控制，不要偷懶；前端調(diào)用后端的接口，必須由后端作二次校驗，不能只相信前端頁面控制；不相信前端傳進來的和權(quán)限有關(guān)的參數(shù)（或者不要讓前端傳進來和權(quán)限有關(guān)的參數(shù)），而是后端自動獲取當前登錄用戶的權(quán)限相關(guān)的信息；后端不能只判斷用戶是否登錄，而是還要判斷當前用戶是否有權(quán)限；特別小心傳入id來查詢或操作的場景，一定要校驗當前用戶是否有該id的權(quán)限；
參見：
- Web業(yè)務安全測試方法（1）—越權(quán)測試
數(shù)據(jù)竊聽
風險：在調(diào)用API的傳輸過程中，數(shù)據(jù)可能會被竊聽，比如惡意WIFI、DNS劫持、網(wǎng)絡設備被黑等。
防范：
盡量在安全的網(wǎng)絡中傳輸，比如內(nèi)網(wǎng)、專線等；采用HTTPS協(xié)議對傳輸過程加密；對傳輸?shù)臄?shù)據(jù)進行加密。
DDoS攻擊
風險：攻擊者控制一群肉雞，發(fā)起DDoS攻擊（分布式拒絕服務攻擊），導致接口被網(wǎng)絡請求堵塞，無法正常服務。
防范：
采用WAF和防火墻；采用流量清洗和黑洞技術(shù)；設置IP白名單；對接口調(diào)用頻率和調(diào)用次數(shù)進行限制。
資源耗盡攻擊
風險：攻擊者利用接口漏洞來耗盡服務端資源。
防范：
限制上傳文件類型和文件大小；限制分頁查詢時每頁的最大記錄數(shù)；限制接口調(diào)用頻率和調(diào)用次數(shù)；限制其它可能耗盡服務端資源的行為。
重放攻擊（Replay Attack）
風險：攻擊者獲取一段報文后，重復多次請求接口。
防范：
在請求報文中加入隨機數(shù)（nonce）和簽名，如果隨機數(shù)重復則服務端認為是無效請求；(該方法的不足是需要維護一張隨機數(shù)的全表記錄，如果用Redis來存儲可能會占用較大內(nèi)存)在請求報文中加入時間戳（timestamp）和簽名，如果請求報文的時間戳與服務端的時間差較大（比如1分鐘），則認為是無效請求；（該方法的不足是在允許的時間差內(nèi)，仍然有被重放攻擊的風險）結(jié)合nonce和timestamp機制（只在允許的時間差內(nèi)維護隨機數(shù)的全表記錄，比如在Redis中隨機數(shù)全表記錄有效期只保留1分鐘，這樣就可以節(jié)約內(nèi)存）；一次性token機制，token使用一次后就失效。
參見：
- 防止重放機制
- https://www.kaspersky.com/resource-center/definitions/replay-attack
注入攻擊
風險：攻擊者傳入一些畸形數(shù)據(jù)，讓接口執(zhí)行一些意想不到的操作。
防范：
程序和數(shù)據(jù)分離，不允許調(diào)用者來控制如何執(zhí)行程序；使用預編譯SQL，而不是動態(tài)拼接SQL；在接口入?yún)ο笾兄环疟匾膶傩?#xff0c;且操作時只修改必要的屬性。（防止利用JSON字符串和Object自動綁定特性，來傳入多余的JSON屬性，來更新整個對象）。
篡改數(shù)據(jù)
風險：攻擊者獲得一段報文后，篡改報文中的內(nèi)容，再請求接口。
防范：
采用API簽名（sign）方式來防止數(shù)據(jù)被篡改；客戶端對請求報文進行簽名，服務端驗簽通過后，才響應請求；服務端對響應報文進行簽名，客戶端驗簽通過后，才相信響應報文；常用的簽名算法包括SHA256或MD5，推薦使用SHA256（哈希算法，簽名不可逆計算出原始值）；簽名時需要同時考慮防止簽名被預測和重放攻擊，需要將nonce和timestamp一起簽名，保證每次簽名（sign）值都不同；
參見：
代碼泄漏
風險：代碼或程序中含有敏感信息，當代碼或程序泄漏后，敏感信息也被泄漏。
防范：
不要在前端代碼中存放secret等敏感信息，即使已經(jīng)加密過的secret；正確配置.gitignore，不要將一些不應該提交的代碼或配置文件放到了Web服務器上，特別是前端代碼；代碼中含有一些測試用的管理用的“秘密”API URL；代碼中含有一些過時且保護不當?shù)腁PI URL；防止泄漏代碼到互聯(lián)網(wǎng)上，比如GitHub；在后端服務器上，在受控的服務配置中心來配置敏感信息；
數(shù)據(jù)泄漏
風險：接口返回了過多的數(shù)據(jù)，包括敏感數(shù)據(jù)。
防范：
只返回必要的數(shù)據(jù)給前端，不要依賴前端來隱藏數(shù)據(jù)；由后端來對敏感數(shù)據(jù)進行脫敏，不要依賴于前端進行脫敏。
API URL泄漏
風險：使用HTTP GET調(diào)用API時，API URL上帶有參數(shù)，因為API URL是明文傳輸?shù)?#xff0c;因此網(wǎng)絡中的網(wǎng)絡節(jié)點都可能竊取這些參數(shù)數(shù)據(jù)。
防范：
不要在API URL中放敏感信息；盡量使用HTTP POST，來在HTTP Request body中傳輸參數(shù)，再采用HTTPS協(xié)議對傳輸過程加密；
服務端被黑
風險：雖然大多數(shù)攻擊都發(fā)生在客戶端向服務端的調(diào)用過程，但是如果服務端被黑，也會導致客戶端面臨風險。
防范：
做好服務端安全防范工作，最小權(quán)限原則，網(wǎng)絡隔離，開放最少端口，設置安全組，漏洞掃描，入侵檢測，告警等；客戶端對服務端的返回數(shù)據(jù)也要驗簽，防止響應數(shù)據(jù)被篡改（比如攻擊者在服務端前安插了一個代理服務器來篡改返回的數(shù)據(jù)）；
攻擊者的常用手段
攻擊者的常用手段：
網(wǎng)絡竊聽；抓包工具；Chrome瀏覽器開發(fā)者工具；編寫Python程序進行來請求接口；病毒程序。
API安全小結(jié)
互不信任原則：接口提供方不信任接口調(diào)用方的請求參數(shù)，接口調(diào)用方不信任接口提供方的返回數(shù)據(jù)；不信任網(wǎng)絡原則：假設網(wǎng)絡傳輸過程是不安全的，網(wǎng)絡中的每一個節(jié)點都是不安全的；采用HTTPS協(xié)議，保證傳輸過程安全；作最壞的打算，即使數(shù)據(jù)被竊聽，也無法解密；設立網(wǎng)絡安全邊界，采用WAF、防火墻、網(wǎng)絡隔離、IP白名單、流量清洗和黑洞技術(shù)來防止DDoS攻擊；使用API網(wǎng)關(guān)，在API網(wǎng)關(guān)上實現(xiàn)安全機制和限流，簡化API實現(xiàn)；采用包含了nonce和timestamp的API簽名來防止數(shù)據(jù)被篡改和重放攻擊；時刻關(guān)注水平越權(quán)問題；注意編碼安全，防止代碼泄漏和API URL泄漏；
安全三要素
簡化的安全三要素：
- 加密（Encryption）：數(shù)據(jù)傳輸過程加密，敏感數(shù)據(jù)存儲加密。
- 認證（Authentication）：識別是誰，定義哪些是公開資源，哪些是需要用戶登錄后才能訪問的資源。
- 鑒權(quán)（Authorization）：允許或拒絕用戶的某些操作。
參考文檔
- 移動應用微信登錄開發(fā)指南
- 微信支付-小程序支付安全規(guī)范
擴展閱讀
- OWASP TOP 10
- OWASP Top 10 Web Application Security Risks
總結(jié)
以上是生活随笔為你收集整理的API安全风险与防范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。
