API(應(yīng)用程序編程接口)可以定義為一組指令,用代碼編寫,允許通過 Internet 在軟件之間進(jìn)行通信。API 已成為整個(gè) DevOps 流程的關(guān)鍵組成部分,不僅允許軟件和服務(wù)器之間通過 Internet 進(jìn)行無縫集成和通信,而且還改進(jìn)了整個(gè) DevOps 流程并允許相對(duì)輕松地構(gòu)建更復(fù)雜的軟件。使用 API 所取得的成功見證了其使用率和流行度的飆升,尤其是在過去 12 個(gè)月中。
昨天的 API 攻擊與今天的 API 攻擊
由于 API 越來越受歡迎,它們已成為網(wǎng)絡(luò)攻擊的重點(diǎn)。僅在過去 12 個(gè)月中,API 攻擊流量就增長了 681%,95% 的公司根據(jù)研究報(bào)告報(bào)告了 API 安全事件。API 攻擊可以描述為出于惡意目的濫用或非法使用或嘗試使用 API,通常是為了非法訪問服務(wù)器以泄露數(shù)據(jù)或?qū)е路?wù)中斷。
過去,API 攻擊主要依賴于針對(duì)已知漏洞,例如 SQL 注入攻擊和 XSS 攻擊。如今,API 攻擊要復(fù)雜得多——不良行為者會(huì)戳戳刺探以了解公司 API 中的業(yè)務(wù)邏輯漏洞并瞄準(zhǔn)這些漏洞。
昨天的 API 攻擊是如何運(yùn)作的?
由于 API 充當(dāng)軟件之間通過 Internet 進(jìn)行通信的網(wǎng)關(guān),因此它們通常存儲(chǔ)有關(guān)實(shí)現(xiàn)方法及其結(jié)構(gòu)的敏感信息。當(dāng)攻擊者獲得此信息的訪問權(quán)限時(shí),它可用于發(fā)起網(wǎng)絡(luò)攻擊,尤其是利用已知 API 漏洞或配置不當(dāng)?shù)?API 的攻擊。因此,當(dāng)濫用 API 的漏洞導(dǎo)致未經(jīng)授權(quán)的訪問或數(shù)據(jù)泄漏時(shí),API 攻擊就會(huì)起作用。
已知 API 漏洞的類型以及如何防范它們
SQL 注入攻擊——SQL 注入攻擊使用特制的惡意 SQL 代碼通過 SQL 數(shù)據(jù)庫插入輸入字段,以潛在地訪問不打算顯示的信息。代碼開發(fā)不良的應(yīng)用程序更容易受到 SQL 攻擊。
XSS 注入攻擊——與 SQL 攻擊類似,跨站點(diǎn)腳本 (XSS) 攻擊使用惡意制作的 JavaScript 代碼插入輸入字段,以潛在地訪問數(shù)據(jù)庫并非法訪問信息。同樣,當(dāng)軟件開發(fā)不當(dāng)時(shí),也會(huì)發(fā)生 XSS 攻擊。
推薦
應(yīng)實(shí)施輸入驗(yàn)證。輸入驗(yàn)證確保用戶輸入與預(yù)期參數(shù)匹配。這些可以防止 SQLi 和 XSS 攻擊。
其他類型的 API 攻擊
如今,大多數(shù)攻擊的目的是通過利用 API 漏洞獲得對(duì)服務(wù)器的未授權(quán)訪問,隨后導(dǎo)致服務(wù)中斷或數(shù)據(jù)被盜。針對(duì) API 的一些最常見的攻擊是:
DDoS 攻擊
當(dāng)攻擊者通過同時(shí)請(qǐng)求數(shù)千個(gè)連接來淹沒 API 的內(nèi)存時(shí),就會(huì)發(fā)生針對(duì) API 的分布式拒絕服務(wù) (DDoS) 攻擊。目的是通過使可用資源無法訪問來淹沒內(nèi)存并導(dǎo)致服務(wù)中斷。雖然 DDoS 攻擊不會(huì)導(dǎo)致信息泄露,但它們的目的是阻撓。
建議——應(yīng)監(jiān)控、過濾和驗(yàn)證所有入站流量。還應(yīng)實(shí)施速率限制。
中間人攻擊 (MiTM)
當(dāng)攻擊者偷偷攔截、中繼和/或修改兩個(gè)客戶端之間的請(qǐng)求或通信時(shí),就會(huì)發(fā)生中間人攻擊。對(duì)于 API,攻擊者可以攔截會(huì)話令牌發(fā)布 API 和 HTTP 標(biāo)頭與用戶之間的通信。這可能會(huì)授予攻擊者對(duì)用戶帳戶的訪問權(quán)限,從而可能導(dǎo)致數(shù)據(jù)和個(gè)人信息被盜。
建議——所有網(wǎng)絡(luò)通信都應(yīng)使用 TLS 加密。TLS 確保連接保持私密,每個(gè)連接都有一個(gè)唯一生成的加密密鑰。
資產(chǎn)管理不當(dāng)
當(dāng)有不止一種方法訪問應(yīng)用程序數(shù)據(jù)庫環(huán)境時(shí),就會(huì)發(fā)生這種類型的 API 攻擊。通常,在應(yīng)用程序的生產(chǎn)狀態(tài)期間,多個(gè) API 端點(diǎn)連接到生產(chǎn)環(huán)境;當(dāng)這些端點(diǎn)被遺忘且未被刪除時(shí),攻擊者就有機(jī)會(huì)使用它們發(fā)出 API 請(qǐng)求并可能獲得對(duì)敏感數(shù)據(jù)的訪問權(quán)限。
建議——應(yīng)正確記錄生產(chǎn)階段使用的所有 API,以便刪除多余的 API 以防止未經(jīng)授權(quán)的訪問。
通信加密不佳
傳輸層安全 (TLS) 為 Internet 上的數(shù)據(jù)傳輸提供最基本的加密形式。這確保了傳輸?shù)臄?shù)據(jù)無法以純文本形式讀取,從而在傳輸敏感數(shù)據(jù)時(shí)增加了一層安全性。加密不當(dāng)?shù)牧髁靠赡軐?dǎo)致 MiTM API 攻擊。
建議——TLS 應(yīng)該跨網(wǎng)絡(luò)使用,因此網(wǎng)絡(luò)流量是加密的,因此在 MiTM 攻擊的情況下,攻擊者無法讀取數(shù)據(jù)。
過多的數(shù)據(jù)暴露
Web 應(yīng)用程序使用 API 定期處理和傳輸敏感數(shù)據(jù)。因此,可能會(huì)發(fā)生數(shù)據(jù)泄露,通常是在 API 未在響應(yīng)到達(dá)客戶端之前對(duì)其進(jìn)行過濾時(shí)。數(shù)據(jù)泄露可能導(dǎo)致未經(jīng)授權(quán)訪問信用卡信息、會(huì)話令牌、密碼、私人健康信息等信息。
建議——應(yīng)過濾和驗(yàn)證所有 API 調(diào)用和響應(yīng),以便只允許授權(quán)的請(qǐng)求和響應(yīng)通過。
損壞的用戶身份驗(yàn)證
API 認(rèn)證是一項(xiàng)核心服務(wù),用于識(shí)別和授權(quán)客戶端訪問應(yīng)用程序。當(dāng)會(huì)話和憑證管理都存在弱點(diǎn)時(shí),就會(huì)發(fā)生用戶身份驗(yàn)證失敗的情況。這可能導(dǎo)致身份驗(yàn)證令牌被盜,進(jìn)一步使攻擊者能夠使用它們來暴力破解 Web 應(yīng)用程序或獲得未經(jīng)授權(quán)的訪問。
建議——API 開發(fā)人員應(yīng)確保在構(gòu)建 API 時(shí)符合正確的標(biāo)準(zhǔn),并且應(yīng)避免使用 API 密鑰進(jìn)行用戶身份驗(yàn)證。還應(yīng)實(shí)施多因素身份驗(yàn)證。
損壞的對(duì)象級(jí)別授權(quán)
損壞的對(duì)象級(jí)別授權(quán)是一種不安全的直接對(duì)象引用。當(dāng)未正確設(shè)置對(duì)象級(jí)權(quán)限時(shí)會(huì)發(fā)生這種情況,導(dǎo)致使用用戶輸入功能對(duì)資源進(jìn)行未經(jīng)授權(quán)的訪問。
建議——應(yīng)適當(dāng)管理用戶授權(quán),特別是對(duì)于整個(gè)身份驗(yàn)證過程中的登錄用戶。
批量分配
當(dāng)用戶可以通過利用特制請(qǐng)求來包含對(duì)應(yīng)用程序功能產(chǎn)生不利影響的參數(shù)來覆蓋服務(wù)器端變量時(shí),就會(huì)發(fā)生批量分配。當(dāng)請(qǐng)求主體被解析為對(duì)象或利用某些框架級(jí)別的自動(dòng)綁定功能(如 Spring 和 .NET)時(shí),可能會(huì)發(fā)生批量分配。
建議——開發(fā) API 時(shí)不應(yīng)使用自動(dòng)綁定功能。此外,限制可由客戶端修改的屬性。這可以防止將請(qǐng)求主體解析為對(duì)象。
參數(shù)篡改
當(dāng)攻擊者操縱在服務(wù)器和客戶端之間交換的參數(shù)(通常存儲(chǔ)在 cookie、隱藏的表單字段或 URL 查詢字符串中)以修改或竊取應(yīng)用程序數(shù)據(jù)時(shí),就會(huì)發(fā)生參數(shù)篡改。
建議——Web 應(yīng)用防火墻可以防止參數(shù)篡改。將應(yīng)用程序輸入的格式列入白名單并加密會(huì)話 cookie 也有助于防止參數(shù)篡改。
結(jié)論
隨著 API 繼續(xù)被組織和個(gè)人廣泛用于軟件開發(fā)和集成,有必要了解與使用 API 相關(guān)的風(fēng)險(xiǎn)。這些風(fēng)險(xiǎn)主要與與 API 相關(guān)的漏洞一致。雖然幾乎不可能完全保護(hù) API 免受所有可能的攻擊形式,但了解針對(duì) API 的眾所周知且頻繁的攻擊不僅有助于拓寬您對(duì)它們的理解,還可以讓組織在緩解這些攻擊時(shí)做出正確的決定。