近年來，互聯網上安全漏洞顯著增多。互聯網安全的話題也被技術博客和論壇討論得越來越頻繁:安全性非常重要，尤其是在REST API的世界中。
根據Jitterbit公司2018年API集成狀態報告:
APIs 正在改變商業
令人印象深刻的是，現在有64%的組織機構正在創建用於內部或外部用例的APIs。雖然現在有四分之一的受訪者根本沒有創建APIs，但是有40%的受訪者正在使用內部和外部用例中的APIs。
API的創建和管理落到了開發人員的肩上
如今，大多數利用APIs的組織都依賴開發人員來編寫和管理這些api。33%的受訪者使用專門的技術來管理APIs，而90%的受訪者則依賴開發團隊或外部資源從頭開始編寫APIs。
由於在越來越多的新的雲應用程序之間編寫集成代碼，組織已經不堪重負，因此要求開發人員為業務創建和管理APIs。
REST API安全
在設計、測試和部署REST API時，安全性問題必須是需要考慮的重要方面。隨著REST API的驚人發展，安全級別，大部分時間，在API的設計和開發中被低估了。敏感數據的安全性，無論是組織的還是個人的信息，都是當今困擾開發人員的一個重要因素。REST api也不例外，它是需要針對安全威脅和破壞進行保護的基本系統的一部分。
根據2018年Postman community report (survey)，越來越多的開發者開始關注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架構中，端到端處理意味著一系列潛在的脆弱操作:
- 在進行 from/to the HTTP 消息映射 和資源 URL (controller 映射).
- 實例化表示目標資源的對象並調用所請求的操作時(從控制器調用服務)。
- 在為目標資源(特定於服務的功能)生成狀態表示時。
- 當訪問/修改託管資源狀態(保存到數據庫或存儲中)的後端系統中的數據時。
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(安全斷言標記語言)令牌。
為了防止大量API請求導致DDoS攻擊或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.中間人攻擊( Man-In-The-Middle-Attack)
它是指攻擊者在兩個交互系統之間秘密地更改、截取或中繼通信，並截取它們之間傳遞的私有和機密數據。MITM攻擊發生在兩個階段:攔截和解密。
HTTP和缺乏TLS
在API中缺少傳輸層安全(TLS)實際上相當於向黑客發出公開邀請。傳輸層加密是安全API中最基本的“必備功能”之一。除非使用TLS，否則相當常見的“中間人”攻擊的風險仍然很高。在api中同時使用SSL和TLS，特別是在API公開的情況下。
結論
在開發REST API時，您必須從一開始就注意安全性。考慮使用具有許多內置安全特性的現有API框架。我們使用的是SugoiJS API框架，我們還對其代碼庫以及測試和安全指導做出了貢獻。通過這種方式，安全性被統一地內置，開發人員可以專注於應用程序邏輯。
在這之後，不要忽略分配資源來測試API的安全性。確保測試本文中提到的所有安全威脅。
閱讀更多 程序你好 的文章
