5個REST API安全準則

banq發表於2016-12-20
RESTAPI
當開發REST API時，從一開始就必須注意安全方面。

REST是透過URL路徑元素表達系統中特定實體的手段。REST不是一個架構，而是一種在Web上構建服務的架構風格。 REST允許透過簡單的URL（而不是複雜的請求主體或POST引數）與基於web的系統互動。

1 - 授權

（1）保護HTTP方法
RESTful API通常使用GET（讀），POST（建立），PUT（替換/更新）和DELETE（刪除記錄）。

對於每個資源並非都要提供所有這些操作。 必須確保傳入的HTTP方法對於會話令牌/API金鑰和相關資源集合，操作和記錄都是有效的。

例如，如果您有一個RESTful API的庫，不允許匿名使用者刪除書目錄條目，但他們可以獲得書目錄條目。 另一方面，對於圖書館員，這兩個都是有效的。

請了解CORS，請啟用網站的CORS。

（2）白名單允許的方法
對於某個URL，有多種方法對應實體上的不同操作。

例如，GET請求可能是對應讀取實體，而PUT將更新現有實體，POST將建立一個新實體，DELETE將刪除現有實體。

只允許需要的動詞，其他動詞將返回適當的響應程式碼 （ 例如，禁止一個403）。

（3）保護特權操作和敏感資源集合
並非每個使用者都有權訪問每個Web服務。 這是至關重要的，因為您不希望Web服務的管理被濫用：

https://example.com/admin/exportAllData

這個URL是一個Web服務管理資源，其會話令牌或API金鑰應作為cookie或內容引數傳送，以確保特權集合或操作得到正確保護，防止未經授權的使用。

（4）防止跨站點請求偽造
對於RESTful Web服務公開的資源，重要的是確保任何PUT，POST和DELETE請求都受到防止跨站點請求偽造的保護。 通常，使用基於令牌的方法。

CSRF很容易透過隨機令牌防止XSS。


2 - 輸入驗證

幫助使用者將高質量的資料輸入到您的Web服務中，例如確保郵政編碼對提供的地址有意義，或日期有意義。 如果不是，拒絕該輸入。

現實情況是，任何人都可以呼叫您的Web服務，所以假設每秒執行上百次失敗的輸入驗證的人是沒有好處的。考慮將API限制為每小時或每天一定數量的請求，以防止濫用。

（1）網址驗證
攻擊者可以篡改HTTP請求的任何部分，包括url，查詢字串，標題，Cookie，表單欄位和隱藏欄位，以嘗試繞過網站的安全機制。

常見的輸入篡改攻擊的常用名稱包括：強制瀏覽，命令插入，跨站指令碼，緩衝區溢位，格式字串攻擊，SQL隱碼攻擊，cookie中毒和隱藏欄位操作。

（2）驗證傳入的內容型別
當POSTing或PUTting新資料時，，客戶端將需要指定傳入資料的Content-Type（例如application / xml或application / json）。

伺服器不應該猜測Content-Type

它應該總是檢查Content-Type頭和內容是否是相同的型別。 缺少Content-Type頭或意外Content-Type頭應該導致伺服器拒絕，發出406無法接受響應。

（3）驗證響應型別
REST服務通常允許多種響應型別（例如application / xml或application / json，客戶端透過請求中的Accept頭指定響應型別的首選順序）。

不要簡單地將Accept頭複製到響應的Content-type頭。 如果Accept報頭沒有包含允許的型別中任何一個，則需要拒絕請求（理想情況下使用406 Not Acceptable響應）。

因為典型的響應型別有許多MIME型別，所以重要的是為客戶端特別記錄應該使用哪些MIME型別。

（4）XML輸入驗證
基於XML的服務必須確保透過使用安全的XML解析來保護它們免受常見的基於XML的攻擊。

這通常意味著防範XML外部實體攻擊，XML簽名包裝等。

見http://ws-attacks.org有關此類攻擊的例子。

3 - 輸出編碼

（1）安全頭部
為了確保指定資源的內容被瀏覽器正確解釋，伺服器應始終傳送帶有正確Content-Type的Content-Type頭，並且Content-Type頭最好包含一個字符集。

伺服器還應傳送X-Content-Type-Options：nosniff，以確保瀏覽器不會嘗試檢測不同於實際傳送的內容型別的其它型別（會導致XSS）。

此外，客戶端應該傳送X-Frame-Options：deny來防止舊版本瀏覽器中的drag'n drop clickjacking攻擊。

（2）JSON編碼
JSON編碼器的一個關鍵問題是阻止在瀏覽器中執行任意JavaScript遠端程式碼...或者，如果您在伺服器上使用node.js。 使用正確的JSON序列化程式來正確編碼使用者提供的資料，以防止在瀏覽器上執行使用者提供的輸入，這一點至關重要。

當在瀏覽器DOM中插入值時，強烈建議使用.value / .innerText / .textContent而不是使用.innerHTML來更新，因為這樣可以防範簡單的DOM XSS攻擊。

（3）XML編碼
XML絕不應該由字串連線構建。 它應該始終使用XML序列化器構造。 這確保傳送到瀏覽器的XML內容是可解析的，並且不包含XML注入。

4 - 加密

（1）傳輸中的資料
除非公共資訊是完全只讀的，否則應強制使用TLS，特別是在執行憑證更新、刪除和任何事務操作時。 TLS的開銷在現代硬體上是可以忽略的，具有微小的延遲增加，其對於終端使用者的安全性得到更多的補償。

考慮使用相互認證的客戶端證照為高度特權的Web服務提供額外的保護。

（2）儲存中的資料
在正確處理儲存敏感或管制資料時，建議實現最佳實踐。 有關詳細資訊，請參閱OWASP 2010年前10 - A7不安全加密儲存。

（3）訊息完整性
除了HTTPS / TLS，JSON網路令牌（JWT）是一個開放標準（ RFC 7519 ），它定義了一個JSON物件參與者之間安全地傳送資訊的緊湊且自成一體的方式。

JWT不僅可以用於確保訊息完整性，而且還可以用於訊息傳送者/接收者的認證。

JWT包括訊息體的數字簽名雜湊值，以確保在傳輸期間的訊息完整性。 欲瞭解更多資訊，您可以訪問https://jwt.io/introduction/ 。

5 - HTTP狀態程式碼
HTTP定義了狀態碼。 當設計REST API時，不要只使用200成功或404錯誤。

以下是每個REST API狀態返回程式碼要考慮的一些指南。 正確的錯誤處理可以幫助驗證傳入的請求，並更好地識別潛在的安全風險。

200 OK -回應一個成功的REST API的行動。HTTP方法可以是GET，POST，PUT，PATCH或DELETE。

400錯誤請求 -請求格式錯誤，如訊息正文格式錯誤。

401未授權 -錯誤或沒有提供任何authencation ID /密碼。

403禁止 -當身份驗證成功，但身份驗證的使用者沒有許可權使用請求的資源。

404未找到 -當請求一個不存在的資源。

405不允許的方法 -意外的HTTP方法的錯誤檢查。 例如，RestAPI期待HTTP GET，但使用HTTP PUT。

429太多的請求 -可能存在的DOS攻擊檢測或由於速率限制的請求被拒絕

（1）401和403
401“未授權”的真正含義未經身份驗證的，“需要有效憑據才能作出回應。”

403“禁止”的真正含義未經授權，“我明白您的憑據，但很抱歉，你是不允許的！”

概要
在這篇文章中，介紹了5個RESTful API安全問題和如何解決這些問題的指南。遵循這些準則將導致更安全和高質量的REST API服務和更多的開發人員友好的REST API。

一些方法（例如，HEAD，GET，OPTIONS和TRACE）被定義為安全的，這意味著它們僅用於資訊檢索，並且不應該更改伺服器的狀態。在設計和構建REST API時，您必須注意安全方面。

Top 5 REST API Security Guidelines

相關文章