5個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時,您必須注意安全方面。
相關文章
- REST API的五種規則RESTAPI
- Swift 官方 API 設計準則SwiftAPI
- rest apiRESTAPI
- SharePoint REST API - 使用REST API和jQuery上傳一個檔案RESTAPIjQuery
- Django REST framework API 指南(5):檢視集DjangoRESTFrameworkAPI
- 2017遊戲化趨勢:5個準則遊戲
- Swift 3 的 API 設計準則SwiftAPI
- GraphQL API vs REST APIAPIREST
- 自動型別安全的.NET標準REST庫refit型別REST
- Elasticsearch(二)——Rest APIElasticsearchRESTAPI
- Spark REST API & metricsSparkRESTAPI
- 13 個設計 REST API 的最佳實踐RESTAPI
- [譯 ] 如何使用 AJAX 和 REST API 建立一個圖表(How To Make A Chart Using AJAX & REST API's)RESTAPI
- SharePoint REST API - 一個請求批量操作RESTAPI
- REST : rest_framework.decorators.api_view 實現PATCHRESTFrameworkAPIView
- 改變遊戲規則的 API 設計審查的5個技巧遊戲API
- Web開發基本準則 , Web訪問安全Web
- Chromium團隊的安全開發核心準則
- SharePoint REST API - 確定REST端點URLRESTAPI
- SharePoint REST API - 概述RESTAPI
- http REST API 驗證庫HTTPRESTAPI
- 利用OpenStack Rest API 建立映象RESTAPI
- 撰寫合格的REST APIRESTAPI
- Rest API 的那些事兒RESTAPI
- REST API 最佳入門指南RESTAPI
- 使用 Spring Security JWT 令牌簽名實現 REST API 安全性SpringJWTRESTAPI
- SOA之(5)——REST的SOA(SOA with REST)概念REST
- ASP.NET Web API與Rest web api(一)ASP.NETWebAPIREST
- 30秒無需編碼完成一個REST API服務RESTAPI
- 編寫 Node.js Rest API 的 10 個最佳實踐Node.jsRESTAPI
- iOS UI遷移到Android的5條準則iOSUIAndroid
- Django REST framework API 指南(21):SchemasDjangoRESTFrameworkAPI
- Django REST framework API 指南(8):渲染DjangoRESTFrameworkAPI
- Django REST framework API 指南(6):路由DjangoRESTFrameworkAPI路由
- Django REST framework API 指南(7):解析DjangoRESTFrameworkAPI
- Django REST framework API 指南(15):限流DjangoRESTFrameworkAPI
- 安息吧 REST API,GraphQL 長存RESTAPI
- 安息吧,REST API,GraphQL 長存RESTAPI