互聯網安全是技術博客和論壇討論得越來越頻繁的一個話題，並且理由充分：近年來，眾多引人注目的安全漏洞顯著增多。安全性非常重要，特別是在 REST API 領域。
API 安全性是組織希望在未來幾年內解決的最大挑戰，而安全性挑戰的解決很有可能會成為 API 領域增長的催化劑。
根據 Jitterbit 發佈的 2018 年 API 集成狀況報告：
API 正在改變業務
今天，令人印象深刻的是有 64% 的組織正在創建用於內部或外部用例的 API。雖然有四分之一的受訪者現在根本沒有創建 API，但 40% 的受訪者都利用了內部和外部用例中的 API。
API 的創建和管理由開發人員負責
如今，大多數利用 API 的組織都依賴他們的開發人員來編寫和管理這些 API。儘管 33% 的受訪者使用專門的技術來管理他們的 API，但 90% 的受訪者依靠他們的開發團隊或外部資源從零開始編寫 API。
組織已經被越來越多新的雲應用程序之間的代碼集成壓得喘不過氣來，它們對開發人員提出更多要求，要求他們為業務創建和管理 API 。
REST API 的安全性
在設計、測試及部署 REST API 時，安全性問題是一個必須要考慮的重要方面。隨著 REST API 的飛速發展，在大多數情況下，安全級別在 API 的設計和開發中被低估。目前敏感數據（無論是組織信息還是個人信息）的安全性是困擾開發人員的一個重要因素。REST API 也不例外，它是需要防範安全威脅和漏洞的重要系統的一部分。
據 2018 年 Postman 社區報告（調查）顯示，越來越多的開發者開始關注 REST API 的安全性，並且對 REST API 的信任度也比前一年有所提高：
在本文中，我將介紹當今 IT 界的 7 大 REST API 安全威脅，以引起大家的關注，並幫助大家瞭解那些能夠反映 REST API 性能的安全威脅。
REST 的安全性問題。
REST 通常使用 HTTP 作為其底層協議，這帶來了一系列常見的安全性問題：
潛在的攻擊者可以完全控制 HTTP 請求或 HTTP 響應的每個字節。由於 REST API 通常用於交換在許多服務器中保存執行的信息，因此它可能會導致一些未經發現的漏洞和信息洩漏。攻擊者可能在客戶端（REST API 的消費者，而受害者是 REST API 服務器）也可能在服務端（攻擊者獲得了對 REST API 服務器的控制權）創建一個惡意的流氓應用程序。在這種情況下，使用遠程 REST API 服務消費資源的應用程序是受害者。對使用 REST 作為客戶端或服務端的應用程序，另一方通常完全控制資源，並可以注入任何負載來攻擊資源處理（例如，獲取任意 Java 代碼或系統命令執行）。在 REST 架構中，端到端的處理意味著包含一系列潛在的易受攻擊的操作：
在往返於 HTTP 消息和資源 URL 的映射過程中（控制器映射）。當實例化表示目標資源的對象並調用請求操作（從控制器中調用服務）時。為目標資源（特定於服務的函數）生成狀態表示時。訪問 / 修改託管資源狀態的後端系統中的數據時（保存到數據庫或存儲中）。REST 框架中的分層轉換序列意味著鏈中的一個薄弱環節就可能會使我們的應用程序變脆弱。
7 大 REST API 安全威脅
1. 注入攻擊
在注入攻擊中，危險代碼被嵌入到一個不安全的軟件程序中，以發起攻擊，其中最著名的是 SQL 注入和跨站點腳本攻擊。實際上，這種暴露可以通過將不受信任的數據作為查詢或命令的一部分傳輸到 API 中來操作。該輸入隨後由解釋器實現，這可能會導致攻擊者獲取未經授權的信息訪問權限或造成其他損害。
阻止或拒絕注入攻擊最有效方法是添加輸入驗證，以下是幾個最重要的準則：
驗證輸入：長度、範圍、格式及類型通過在 API 參數中使用強類型（如數字、布爾值、日期、時間或固定數據範圍）來實現隱式輸入參數校驗用正則表達式約束字符串的輸入定義適當的請求大小限制並使用 HTTP 響應狀態 413（請求實體太大）來拒絕超過該限制的請求2. DoS 攻擊
在拒絕服務（DoS）攻擊中，攻擊者在大多數情況下會推送大量消息，請求服務器或網絡建立由無效返回地址組成的請求。如果沒有采取適當的安全防範措施，這種攻擊能夠使 RESTful API 處於無法運行的狀態。最近，無論 API 是否公開，其他人（包括攻擊者）都可以訪問它。
隨著這些 API DoS 攻擊變得變得越來越普遍，並且隨著組織越來越多地依賴 API 來滿足其業務需求，安全專業人員應該開始積極計劃應對此類攻擊。即使禁用用於應用程序身份驗證的 API 密鑰（或訪問令牌），也可以通過標準瀏覽器請求輕鬆地重新獲取密鑰。
因此，使當前訪問令牌失效不是一個長期的解決方案。如果 DoS 攻擊可以追溯到某個特定的 IP 地址，那麼將該 IP 地址列入黑名單也不是長久之計，因為攻擊者可以很容易地獲取一個新的 IP 地址。
這就是為什麼需要多種訪問控制方法的原因。對於非敏感信息，使用 API 密鑰可能就足夠了。然而，為更好地防止 DoS 攻擊，需要使用 HTTPS 和更健壯的身份驗證機制，包括 OAuth 、相互（雙向）TLS（傳輸層安全性）身份驗證或 SAML （安全斷言標記語言）令牌。
為防止可能會導致 DDoS 攻擊或其他 API 服務濫用的大量 API 請求，請在給定時間間隔內對每個 API 的請求數量施加限制（也稱為峰值阻止）。當超過此速率時，至少暫時阻止來自該 API 密鑰的訪問，並返回 429（請求過多）HTTP 錯誤碼。
如果我們開始構建新的 REST API 了，請先檢查下 Web 服務是否具有一些面向安全性的特性。
3. 身份驗證失敗
這些特殊的問題可能使攻擊者繞過或控制 Web 程序使用的身份驗證方法。身份驗證丟失或不足可能會導致攻擊，從而破壞 JSON Web 令牌、API 密鑰、密碼等。
攻擊的目的通常是控制多個帳戶，更不用說攻擊者獲得與被攻擊用戶同等的權限。只有經過身份驗證的用戶才可以訪問這些 API。
使用 OpenId/OAuth 令牌、PKI 和 API 密鑰可以很好地滿足 API 授權和身份驗證需求。最好不要通過未經綁定的連接發送憑據，也不要在 Web URL 中顯示會話 ID。
4. 敏感數據洩露
由於在傳輸中或靜態時缺乏加密而導致的敏感數據暴露可能會導致攻擊。當應用程序無法正確保護敏感數據時，就會發生敏感數據洩漏。這些信息可能是私人健康信息、信用卡信息、會話令牌、密碼等，而且包含越多的信息越容易受到攻擊。敏感數據需要很高的安全性，除了在與瀏覽器進行交換時採取非常規的安全做法外，還包括靜態或傳輸中的加密。
為了避免敏感數據洩露，必須使用 SSL。
今天，我們可以通過 Let’s Encrypt 得到一個免費證書。SSL 和 TLS 在消除基本 API 漏洞方面經驗豐富，幾乎不費吹灰之力。
要想獲得一份有關實施效果的出色報告，請使用 Qualys SSL 服務測試，測試你的 URL。這是我們的測試結果：
5. 訪問控制中斷
訪問控制，在某些情況下稱為授權，是一個 Web 軟件允許某些人而不是所有人訪問它的功能和內容的方式。缺少訪問控制或訪問控制不足可能會使攻擊者可以控制其他用戶帳戶、變更訪問權限、變更數據等。
當開發人員未能正確地配置操作級的可訪問性時，公司應用程序訪問就容易受到攻擊，從而導致訪問漏洞。拒絕訪問是破壞訪問控制的最常見後果，而利用訪問控制是攻擊者的主要手段。
由於某些框架中缺少訪問控制，因此可以通過手動或自動化的方式來檢測訪問控制。如果在可靠的無服務器或服務器端 API 中實現了訪問控制，則訪問控制通常是有效的，因為攻擊者將無法更改訪問控制元數據。
6. 參數篡改
這是一種基於操作客戶端和服務器之間交換的參數來修改應用程序數據（例如，用戶憑據和權限、產品價格和數量等）的攻擊。通常，這些信息存儲在 cookie、隱藏表單字段或 URL 查詢字符串中，用於增強應用程序的功能和控制。
當有害的網站、程序、即時消息、博客或電子郵件使用戶的 Internet 瀏覽器在授權的網站上執行不必要的操作時，就會發生這種情況。它允許攻擊者在被攻擊用戶不知情的情況下，使用目標的 Web 瀏覽器使目標系統執行某個功能，直到未經授權的事務被執行為止。
攻擊能否成功取決於完整性和邏輯驗證機制的錯誤，利用該機制可能還會導致其他攻擊，包括 XSS、SQL 注入、文件包含和路徑洩漏等攻擊。
我們應該仔細地校驗接收到的 URL 參數，以確保該數據能代表來自用戶的有效請求。無效請求可用於直接攻擊 API 或攻擊 API 背後的應用程序和系統。將校驗器放在應用程序上，並嘗試對發送到 REST API 的請求使用 API 簽名。還可以為 API 創建自動化安全測試，以確保沒有參數篡改來影響我們的 REST API。
7. 中間人攻擊 (MITM)
它是指攻擊者秘密地更改、攔截或中繼兩個交互系統之間的通信，並攔截它們之間傳遞的私有和機密數據。MITM 攻擊分為兩個階段：攔截和解密。
HTTP 且缺少 TLS
API 中缺少傳輸層安全性（Transport Layer Security，TLS）實際上等同於向黑客發出公開邀請。傳輸層加密是安全 API 中最基本的“必備條件”之一。除非使用 TLS，否則遭受普遍存在的“中間人”攻擊的風險仍然很高。在 API 中同時使用 SSL 和 TLS 很有必要，尤其是要使用公開 API時。
總結
在開發 REST API 時，必須從一開始就注意安全性。可以考慮使用內置了許多安全特性的現有 API 框架。在 RestCase 中，我們使用的是 SugoiJS API 框架，除測試和安全指導之外，我們還為其代碼庫做出了貢獻。通過這種方式，安全性被統一地內置，並且開發人員可以更專注於應用程序的邏輯。
在這之後，不要忘記分配資源來測試 API 的安全性。一定要測試本文中所提到的所有安全威脅。