保護敏感數據的 8 個 API 安全最佳實踐
- Noname Security - Taiwan
- 2022年6月1日
- 讀畢需時 10 分鐘
Written by Jamie Juviler
企業為了在上線的應用程式實施新的API是非常令人興奮的一步！可以有利的讓第三方開發人員和企業應用程式整合，有助於企業與客戶之間的整合，並且將更多用戶吸引到您的平台時為您帶來利潤。
不幸的是，新的API對駭客來說也是個好消息，因為它們提供了另一種可以利用的管道來擷取在服務器上的信息的方法。
在這篇文章中，我們將解釋 API 安全性的基礎知識，包括針對 API 的常見威脅以及防禦它們的最佳方法，這樣您就可以從這項技術中獲益，而不會遭遇失敗。
什麼是 API 安全性？
API 安全是保護 API 免受網絡攻擊和濫用的做法。適當的 API 安全措施可確保對 API 的所有已處理請求均來自合法來源，所有已處理請求均有效，並且來自 API 的所有響應均受到保護，不會被攔截或利用。
API 的目標是促進您的系統和外部用戶之間的數據傳輸，通常是私有的。因此，維護不善且不安全的 API 是通往敏感數據的未上鎖的大門。
如果這是危言聳聽，請知道數十億條記錄已從網絡攻擊中暴露出來，其中許多是由於不安全的 API：
為什麼 API 安全很重要
雖然網絡安全是一個涵蓋所有在線技術的廣泛主題，但 API 帶來了獨特的挑戰，因為它們位於第三方開發人員和公司資源之間。API 安全漏洞對應用程式及其用戶尤其有害，因為被駭入端點授予對敏感信息的直接訪問權限。
很難誇大成功攻擊的潛在影響。雖然財務影響可能很大，但對您的品牌造成的損害可能是無法彌補的。您肯定會失去客戶的信任，以及使用您的 API 的公司的信譽。第三方整合應用程式甚至可能受到擴展的損害。
API 網絡攻擊的類型
在我們審查強化 API 的最佳實踐之前，我們需要了解我們面臨的挑戰。以下是您應該知道的針對 API 的最常見攻擊：
被盜用的認證
訪問 API 的最簡單方法之一是劫持授權用戶的身份。例如，如果身份認證Token落入壞人之手，它可能會被用來訪問具有惡意意圖的資源，同時看起來是合法的。網絡犯罪分子還將嘗試猜測身份認證密碼或破壞弱身份認證過程以獲得訪問權限。
中間人攻擊(MITM)
當駭客攔截最終用戶和 API 之間的 API 請求或響應時，就會發生中間人 (MITM) 攻擊。他們可能會竊取此通信的敏感內容（例如帳戶登錄憑證或付款信息）或修改請求/響應的內容。
代碼注入
在身份認證和驗證方面存在漏洞的 API 也容易受到代碼注入的影響，其中攻擊者通過 API 請求將腳本發送到ㄌ的服務器。此腳本旨在公開或刪除數據、植入虛假信息和/或損害應用程式的內部結構。您還將看到使用的術語“SQL 注入”——這是在SQL 數據庫上執行的代碼注入。
拒絕服務攻擊
拒絕服務 (DoS) 攻擊通過 API 請求淹沒服務器資源，以減慢、破壞或崩潰 Web 服務器。通常，這些攻擊是由多個惡意來源同時發起的——分佈式拒絕服務 (DDoS) 攻擊。
儘管存在這些風險，API 不會很快消失。幾乎任何尋求與他人集成的在線應用程式都需要一個或多個 API，而每一個新的 Web API 都為駭客提供了利用個人數據的另一個機會。因此，任何監督軟件集成的人都應該了解適當的 API 特定安全措施。
API 安全最佳實踐
1. 實施身份認證。
2. 實施授權。
3. 驗證所有請求。
4. 加密所有請求和響應。
5. 僅在回復中包含必要的信息。
6. 限制 API 請求並建立配額。
7. 記錄 API 活動。
8. 進行安全測試。
雖然任何擁有 API 的組織都可以成為目標，但每個組織都會以不同的方式實施 API 和 API 安全性。提供支付信息訪問權限的 API 需要比圖像共享服務更多的預防措施。
這就是為什麼以下提示是通用的並且適用於任何實現REST API的應用程式的原因。REST API 通過超文本傳輸協議 (HTTP) 傳輸數據，這與用於將 HTML 文檔發送到瀏覽器（我們將其視為網站）的方法相同。許多公共 API和內部 API（例如，在微服務中使用）都使用這種類型的架構。Netflix、Uber 和 Trello 只是少數使用 REST API 的現代應用程式。
通過遵循以下指南，您將大大降低與維護 API 相關的風險，無論您的利基市場如何。
1.實施認證。
在處理請求之前，API 會執行身份認證——它需要驗證發送請求的用戶或程序的身份。
通常，API 使用密碼、多因素身份認證和/或身份認證Token進行身份認證，身份認證Token是用作用戶唯一標識符的字符串。要使用Token對請求進行身份認證，API 會將請求中發送的Token與存儲在其數據庫中的Token進行匹配。Token可幫助組織跟踪受其資源信任的人。
今天，OAuth協議是 API 用戶身份認證的廣泛接受的標準。OAuth 最初是為社交登錄而設計的，允許用戶在不洩露密碼的情況下使用密碼登錄第三方應用程式。例如，OAuth 讓我可以使用我的 Google 密碼登錄到 LinkedIn 等第三方網站，而無需 LinkedIn 存儲我的密碼。
OAuth 基於 HTTP 構建，這也使其非常適合 REST API。雖然 OAuth 的內部工作超出了本文的範圍，但在基本層面上，OAuth 為 API 管理員提供了一種將身份認證Token授予批准的第三方的方法。管理員可以設置自定義訪問規則，根據請求的來源確定允許哪些 API 請求。
2.實施授權。
在驗證發送請求的用戶的身份後，API 需要一種方法來僅授予對授權資源和方法的訪問權限。例如，用戶可能被批准訪問 API，但如果不允許他們通過 POST 方法將信息添加到應用程式的數據庫中，那麼任何這樣做的請求都應該被拒絕。授權信息也可以作為Token包含在請求中。
與其他一些 API 類型不同，REST API 必須對向服務器發出的每個請求進行身份認證和授權，即使多個請求來自同一用戶。這是因為 REST 通信是無狀態的——也就是說，API 可以單獨理解每個請求，而無需來自先前請求的信息。
授權可以由用戶角色管理，其中每個角色都有不同的權限。通常，API 開發人員應遵守最小權限原則，即用戶只能訪問其角色所需的資源和方法，僅此而已。預定義的角色使監督和更改用戶權限變得更加容易，從而減少了不良行為者訪問敏感數據的機會。
3. 驗證所有請求。
如前所述，有時來自完全有效來源的請求可能是駭客攻擊。因此，API 需要規則來確定請求是否友好、友好但無效或有害，例如嘗試注入有害代碼。
API 請求只有在其內容通過徹底的驗證檢查後才會被處理——否則，請求永遠不會到達應用程式數據層。
4. 加密所有請求和響應。
為了防止 MITM 攻擊，從用戶到 API 服務器的任何數據傳輸（反之亦然）都必須正確加密。這樣，如果沒有正確的解密方法，任何被攔截的請求或響應對入侵者都是無用的。
由於 REST API 使用 HTTP，因此可以使用傳輸層安全 (TLS) 協議或其先前的迭代安全套接字層 (SSL)協議來實現加密。這些協議提供“HTTPS”中的 S（“S”表示“安全”），並且是加密網頁和 REST API 通信的標準。一些 CMS 平台將提供免費的 SSL，從第一天起就可以加密您的頁面。但是，如果您的平台不提供像 WordPress 這樣的 SSL，您需要使用 API 或插件添加一個。
TLS/SSL 僅在傳輸數據時加密數據。它不會加密 API 後面的數據，這就是為什麼敏感數據也應該在數據庫層中加密的原因。
除了 SSL，還可以考慮集成Web 應用程式防火牆 (WAF)，該防火牆將監控 Web 流量，以識別和防止 DDoS 攻擊和代碼注入。如果您使用 HubSpot 的免費 CMS，這兩個都已經免費並內置在平台中。
5. 只在回復中包含必要的信息。
就像您在向朋友講述故事時可能無意中洩露了一個秘密一樣，API 響應可能會暴露駭客可以使用的信息。為防止這種情況，發送給最終用戶的所有響應應僅包括傳達請求成功或失敗的信息、請求的資源（如果有）以及與這些資源直接相關的任何其他信息。
換句話說，避免“過度共享”數據——響應是您通過返回的資源或詳細的狀態消息無意中暴露私人數據的機會。
6.限制API請求並建立配額。
為了防止像 DDoS 這樣的蠻力攻擊，API 可以施加速率限制，這是一種在任何給定時間控制對 API 服務器的請求數量的方法。
有兩種主要的方式來限制 API 請求，配額和限制。配額限制了用戶在一段時間內允許的請求數量，而節流會減慢用戶的連接速度，同時仍允許他們使用您的 API。
這兩種方法都應該允許正常的 API 請求，但要防止旨在中斷的流量氾濫，以及一般的意外請求峰值。
7. 記錄 API 活動。
到目前為止，我們已經介紹了應對 API 威脅的先發製人方法。但是，如果您的系統被成功入侵，您將需要一種方法來追踪事件的來源，以便您可以補救和報告問題。
這就是為什麼記錄所有 API 活動是必不可少的——如果攻擊者違反了您的保護措施，您可以評估他們做了什麼以及他們是如何進入的。如果不出意外，您可以使用攻擊來進一步強化您的 API，從而可能防止未來發生類似事件.
8. 進行安全測試。
不要等到真正的攻擊才能看到您的保護措施是否有效。相反，請留出充足的時間進行安全測試，在這些測試中，您會故意破解您的 API 以暴露漏洞。請記住：測試不是一個一次性的過程——它應該定期執行，尤其是在您的 API 更新時。
讓我們仔細看看下面的這一步。
API 安全測試
API 安全性的第一步是確保您的 API 按預期工作。這意味著通過 API 客戶端提交正常請求並確保它們遵守上述原則。開發能夠回答以下問題的場景：
只有經過身份認證的用戶才能訪問您的端點嗎？
用戶是否僅根據其角色授予對必要端點的訪問權限？
每個潛在請求的響應中是否返回了正確的信息？
良性但無效的請求是否被拒絕？
一旦您確定您的 API 工作正常，您將需要在適當的測試環境中針對您的系統模擬代碼注入、MITM、DoS 和盜竊密碼攻擊。在您的測試中解決以下問題：
我的身份認證可以對抗蠻力進入嘗試嗎？
我的 API 如何處理請求中的顯著峰值？
如果經過身份認證的用戶通過請求提交了有害的腳本或文件怎麼辦？
所有數據傳輸都加密了嗎？是否禁止沒有 TLS/SSL（即使用 HTTP 而不是 HTTPS）的請求？
如果請求或響應被攔截怎麼辦？我的 API 和用戶如何知道？
以下是您可以運行的一些特定測試。
用戶認證測試
如果身份認證機制實施不正確，攻擊者可能會破壞身份認證Token或利用實施缺陷來冒充其他用戶的身份並獲得對您 API 端點的訪問權限。
要測試您的身份認證機制，請嘗試在沒有正確身份認證的情況下發送 API 請求（沒有Token或憑據，或者不正確的），並查看您的 API 是否以正確的錯誤和消息響應。
參數篡改測試
要運行參數篡改測試，請在您的 API 請求中嘗試各種無效查詢參數的組合，看看它是否以正確的錯誤代碼響應。如果沒有，那麼您的 API 可能存在一些需要解決的後端驗證錯誤。
注塑測試
要測試您的 API 是否容易受到注入攻擊，請嘗試在 API 輸入中註入 SQL、NoSQL、LDAP、OS 或其他命令，並查看您的 API 是否執行它們。這些命令應該是無害的，例如重啟命令或 cat 命令。
未處理的 HTTP 方法測試
大多數 API 都有各種用於檢索、存儲或刪除數據的 HTTP 方法。有時 Web 服務器會默認訪問不受支持的 HTTP 方法，這會使您的 API 易受攻擊。
要測試此漏洞，您應該嘗試所有常見的 HTTP 方法（POST、GET、PUT、PATCH 和 DELETE）以及一些不常見的方法。例如，嘗試使用 HEAD 動詞而不是 GET 發送 API 請求，或者使用 FOO 等任意方法發送請求。您應該會收到一個錯誤代碼，但如果您收到 200 OK 響應，則說明您的 API 存在漏洞。
模糊測試
模糊測試應該是 API 安全審查過程的最後步驟之一。這種類型的測試需要將您的 API 推到其極限，以便發現任何尚未發現的功能或安全問題。
為此，請發送大量隨機請求，包括 SQL 查詢、系統命令、任意數字和其他非文本字符，並查看您的 API 是否響應錯誤、處理任何這些輸入不正確或崩潰。這種類型的測試將模擬溢出和DDoS 攻擊。
API 管理器或Gateway工具將處理或幫助解決上述 API 安全指南（包括測試）。下面讓我們仔細看看這些工具。
API 安全管理
借助 API 管理平台，您可以在一處保護跨環境和供應商的所有 API 和端點。您還可以通過分配預配置的安全身份認證配置文件、創建和自定義可用於保護所有 API 或單個 API 的策略等來自動化部分 API 安全過程。
可以說，API 管理平台最重要的功能是訪問控制。他們應該防止未經授權的用戶獲得對您的 API 服務和數據的不適當級別的訪問權限。
為了實施訪問控制，大多數 API 管理平台支持至少一種或所有三種類型的安全方案，如下所述：
API 密鑰：提供唯一身份認證信息的單個Token字符串。
基本身份認證：提供唯一身份認證信息的兩個Token字符串解決方案，如用戶名和密碼。
OpenID Connect (OIDC)：位於 OAuth 框架之上的簡單身份層，它通過獲取基本配置文件信息（例如，使用身份認證服務器）來驗證用戶。
Noname Security Active Testing 是一個針對 AppDev/DevOps 組的新模塊，可幫助將“Shift Left”測試深入到應用程序開發過程中。 通過將 API 測試轉移到應用程式開發過程中，它可以幫助 AppDev/DevOp 團隊將經過徹底測試的 API 發佈到生產中，並避免在開發結束時造成測試瓶頸。 這減少了前期風險和補救工作，從而使 AppDev/DevOps 小組能夠始終如一地維護他們的測試版本。
Kommentare