5個REST API安全準則

banq發表於2016-12-20
當開發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

相關文章