分析RESTful API安全性及如何採起保護措施

本文中討論了API安全性和採用安全措施的重要性，如身份驗證，API密鑰，訪問控制和輸入驗證。

API設計的第一步是撰寫接口文檔

根據TechTarget（海外IT專業媒體）的定義，RESTful API是一個應用程序接口，它使用HTTP請求來獲取GET，PUT，POST和DELETE等數據。從技術層面上看，RESTful API（也稱爲RESTful Web服務）是一種基於表明性狀態轉移（REST）技術，這是一種一般用於Web服務開發的架構風格和通訊方法。

但隨着 RESTful API 應用範圍的爆炸性擴大，安全性愈來愈成爲API架構設計中最容易被忽視的部分。

 

爲何API安全性很重要？

在設計和部署RESTful API時，有如下三個核心緣由能夠解釋爲何安全性應該是一個很重要的考慮因素。

1.數據保護

RESTful API是一種向外界傳輸價值的服務方式。所以，保護經過RESTful方式提供的數據始終應該是屬於高優先級。

2.DOS攻擊

若是不採起正確的安全措施，（DOS）攻擊可使RESTful API進入非功能狀態。考慮到不少基礎的RESTful API是開放給全部人使用的狀況，經過這種相似開源的方式有助於它更好推廣給市場，讓更多人投入使用，但同時意味着若是有人選擇對API執行DOS攻擊時，它也可能致使災難性的結果。

3.商業影響

現在有越來多的服務平臺，提供着影響衣食住行的各類信息，從飛機航班時刻表到高鐵餘票查詢，甚至只是超市裏平常用品，都能給你提供價格、數量、時間等諸多信息，讓你足不出戶，買到最合心意的商品。在這樣的大趨勢下，這種利用API數據來獲取更多信息，再提供給你的聚合服務平臺將會愈來愈多。因而經過RESTful API傳輸的信息會被頻繁調用，而其中的我的信息很容易被泄露。

保障安全採用的措施

如下介紹一些RESTful API通用設計中的關鍵概念。

1.會話管理和認證

除了使用TLS / HTTPS以外，最重要的RESTful API安全級別是以會話管理和身份驗證爲中心的。在本文討論中重點將放在API密鑰，OpenID Connect / OAuth2 / SAML和會話狀態事項上。

2.API密鑰

API密鑰的概念是爲使用者提供了做爲其HTTP請求的一部分的惟一字符串（密鑰）。雖然不是一個完整的安全解決方案，但與匿名使用相比，使用API密鑰能夠更清楚地瞭解誰在使用API。

API密鑰也可用於提供附加服務。例如，對於RESTfulAPI，附加的服務能夠選擇使用不一樣的級別。以通常、高、最高三個等級爲例，在「通常」的級別，用戶能夠自由訪問，但只能訪問一組有限的數據。假如要訪問更多組的數據，那就必須支付費用才能訪問「高」的級別，以此類推，不受限制的訪問全部的數據則要支付「最高」等級的費用，經過提供不一樣API密鑰的方式，提供額外的服務。

使用API密鑰的最經常使用的方式是將它們包含在請求頭中。

例如，當調用某個小部件的頭部時，67A73DD1BD1D90210BA的API設置爲HTTP頭部中的X-API-KEY鍵/值對：

curl-H「X-API-鍵：67A73DD1BD1D90210BA」

API密鑰的另外一個常見用法是將該密鑰包含在URI中：

https://www.example.com/v1/widgets?api_key= 67a73dde1bdd1d90210ba

但這種方法的問題在於，API密鑰在瀏覽器歷史記錄和對應服務器的日誌中都會顯示出來，意味着向全部有權訪問這些數據的人公開惟一密鑰。

3.OpenID Connect，OAuth2和SAML

OpenID Connect，OAuth2和SAML使用HTTP協議做爲傳輸，用於安全目的。身份驗證提供我的的驗證，同時受權執行或撤消訪問的任務。

從身份驗證角度來看，存在如下選項：

1. OpenID Connect：能夠利用現有的身份提供商（如Google或Facebook）獲取用於驗證用戶受權的令牌。
2. OAuth2：能夠經過受權執行僞認證（以下所述）。
3. SAML：使用斷言、協議、綁定和配置文件來管理身份驗證，包括標識提供者，但不太適合移動應用程序驗證。

爲提供受權服務，採用如下策略：

• OAuth2：提供安全的委託訪問，經過容許第三方身份提供程序頒發令牌來表明用戶執行操做。因爲OAuth2必須瞭解被委派的用戶，所以身份驗證是以僞方式實現的（如上所述）。
• SAML：對可信服務執行斷言，包括提供受權的令牌。

4.會話狀態事項

RESTful API端點應始終保持無狀態會話狀態，這意味着會話的全部內容都必須保存在客戶端。來自客戶端的每一個請求都必須包含服務器理解請求所必需的全部信息。爲了簡化流程，包括API令牌以及會話令牌，做爲每一個業務中都須要的一部分。

5.訪問控制

如上所述，對RESTful服務的受權能夠將安全性引入到所提供的端點中，以便對那些能夠向API發出HTTP刪除請求的人有限制。

在下面的簡單Java示例中，只有Admin和Manager角色（即組）的成員能夠執行刪除全部用戶的DELETE請求，可是全部用戶均可以執行GET請求以獲取用戶列表：

 

6.速率限制

如上所述，API密鑰是判斷RESTful API的使用者身份級別一種頗有用的策略。除了提供等級識別外，使用API密鑰的另外一個好處是可以限制API的使用，例子像Tibco Mashery、MuleSoft和Dell Boomi等API管理解決方案容許限制API請求，利用API密鑰實現此功能。所以，試圖執行DoS攻擊（有意或無心）的時候將會達到一個設定的閾值，到達閾值後後續全部的請求都將被拒絕。

7.輸入驗證和HTTP返回代碼

在保護RESTful API時，應始終考慮對輸入進行驗證。例如，若是用戶試圖發佈與地址相關的JSON數據集合，則RESTful端點內的服務應驗證數據並使用HTTP返回代碼來反映正確的狀態。在下面簡化的Java示例中，就是調用一個很是基本的AdvSersService來驗證和保存地址：

在上面的示例中，使用isValidAddress（）方法驗證newAddress對象（從JSON編組到Address Java對象）。若是地址無效，則向用戶返回HTTP 401（錯誤請求）代碼，文本顯示爲「提供的地址無效。」 若是認爲該地址有效，則convertAddress（）將執行必要的操做，而後將包含地址內容的JSON格式的字符串返回給用戶，以及一個HTTP 201（建立）返回代碼。

結論

保護RESTful API的安全應該始終處於API設計工做中最早被考慮的部分。若是不保護敏感數據，容許DOS攻擊以及不考慮使用RESTful API的影響，那麼即便它只是短暫的影響，相關的風險可能很容易使企業處於不利地位。

受權和身份驗證能夠爲RESTful API提供必要的安全性，實現API密鑰策略能夠有效的用最低成本保護RESTful API的安全。對輸入內容進行驗證始終應該是RESTful API的一部分，由於沒法保證API後續是否會進行任何須要的驗證，同時返回到客戶端的結果應該符合預設中HTTP返回代碼，而不只僅只是狀態碼顯示的成功（200）或者錯誤（404）。

除了API的安全性須要被保護，時刻掌握API運行中的動態也是很重要的事情。最近發掘了一個新的工具：EOLINKER，他們自己是作API研發管理服務，因工做緣由最近一直使用他們的另外一個產品：API監控，最大的改變就是能隨時查看接口是否報錯，報錯時能夠查看錯誤的地方，對比以前效率高了很多，對API管理、監控等方面有興趣的小夥伴自行了解下哦！https://www.eolinker.com

你使用過RESTful API嗎？又對RESTful API安全性有什麼見解？歡迎在下方留言一塊兒討論哦。

 

原標題：RESTful API Security

做者：John Vester

翻譯和修改：隔壁王書

原文地址：https://dzone.com/articles/restful-api-security