轉載鏈接:blog.nsfocus.net/rest-api-design-safety/
REST API 安全設計指南。REST的全稱是REpresentational State Transfer，它利用傳統Web特點，提出提出一個既適于客戶端應用又適于服務端的應用的、統一架構，極大程度上統一及簡化了網站架構設計。
目前在三種主流的Web服務實現方案中，REST模式服務相比復雜的SOAP和XML-RPC對比來講，更加簡潔，越來越多的web服務開始使用REST設計并實現。但其缺少安全特性，《REST API 安全設計指南》就是一個REST API安全設計的指南，權當拋磚引玉，推薦網站后臺設計及網站架構師們閱讀。
1，REST API 簡介
REST的全稱是REpresentational State Transfer，表示表述性無狀態傳輸，無需session，所以每次請求都得帶上身份認證信息。rest是基于http協議的，也是無狀態的。只是一種架構方式，所以它的安全特性都需我們自己實現，沒有現成的。建議所有的請求都通過https協議發送。RESTful web services 概念的核心就是“資源”。 資源可以用 URI 來表示。客戶端使用 HTTP 協議定義的方法來發送請求到這些 URIs，當然可能會導致這些被訪問的”資源“狀態的改變。HTTP請求對應關系如下：
對于請求的數據一般用json或者xml形式來表示，推薦使用json。
2，身份認證
身份認證包含很多種，有HTTP Basic，HTTP Digest，API KEY，Oauth，JWK等方式，下面簡單講解下：
2.1 HTTP Basic
REST由于是無狀態的傳輸，所以每一次請求都得帶上身份認證信息，身份認證的方式，身份認證的方式有很多種，第一種便是http basic，這種方式在客戶端要求簡單，在服務端實現也非常簡單，只需簡單配置apache等web服務器即可實現，所以對于簡單的服務來說還是挺方便的。但是這種方式安全性較低，就是簡單的將用戶名和密碼base64編碼放到header中。
正是因為是簡單的base64編碼存儲，切記切記在這種方式下一定得注意使用ssl，不然就是裸奔了。 在某些產品中也是基于這種類似方式，只是沒有使用apache的basic機制，而是自己寫了認證框架，原理還是一樣的，在一次請求中base64解碼Authorization字段，再和認證信息做校驗。很顯然這種方式有問題，認證信息相當于明文傳輸，另外也沒有防暴力破解功能。
2.2 API KEY
API Key就是經過用戶身份認證之后服務端給客戶端分配一個API Key，類似：http://example.com/api?key=dfkaj134,一般的處理流程如下： 一個簡單的設計示例如下： client端：
server端：
client端向服務端注冊，服務端給客戶端發送響應的api_key以及security_key，注意保存不要泄露，然后客戶端根據api_key,secrity_key,timestrap,rest_uri采用hmacsha256算法得到一個hash值sign，構造途中的url發送給服務端。 服務端收到該請求后，首先驗證api_key,是否存在，存在則獲取該api_key的security_key，接著驗證timestrap是否超過時間限制，可依據系統成而定，這樣就防止了部分重放攻擊，途中的rest_api是從url獲取的為/rest/v1/interface/eth0,最后計算sign值，完之后和url中的sign值做校驗。這樣的設計就防止了數據被篡改。 通過這種API Key的設計方式加了時間戳防止了部分重放，加了校驗，防止了數據被篡改，同時避免了傳輸用戶名和密碼，當然了也會有一定的開銷。
2.3 Oauth1.0a或者Oauth2
OAuth協議適用于為外部應用授權訪問本站資源的情況。其中的加密機制與HTTP Digest身份認證相比，安全性更高。使用和配置都比較復雜，這里就不涉及了。
2.4 JWT
JWT 是JSON Web Token，用于發送可通過數字簽名和認證的東西，它包含一個緊湊的，URL安全的JSON對象，服務端可通過解析該值來驗證是否有操作權限，是否過期等安全性檢查。由于其緊湊的特點，可放在url中或者 HTTP Authorization頭中，具體的算法就如下圖
3 授權
身份認證之后就是授權，根據不同的身份，授予不同的訪問權限。比如admin用戶，普通用戶，auditor用戶都是不同的身份。簡單的示例：
上述是垂直權限的處理，如果遇到了平行權限的問題，如用戶A獲取用戶B的身份信息或者更改其他用戶信息，對于這些敏感數據接口都需要加上對用戶的判斷，這一步一般都在具體的邏輯實現中實現。
4 URL過濾
在進入邏輯處理之前，加入對URL的參數過濾，如
限定num位置為整數等，如果不是參數則直接返回非法參數，設定一個url清單，不在不在url清單中的請求直接拒絕，這樣能防止開發中的api泄露。rest api接口一般會用到GET,POST,PUT,DELETE,未實現的方法則直接返回方法不允許，對于POST，PUT方法的數據采用json格式，并且在進入邏輯前驗證是否json，不合法返回json格式錯誤。
5 重要功能加密傳輸
第一步推薦SSL加密傳輸，同時對于系統中重要的功能做加密傳輸，如證書，一些數據，配置的備份功能，同時還得確保具備相應的權限，這一步會在授權中涉及。
6 速率限制
請求速率限制，根據api_key或者用戶來判斷某段時間的請求次數，將該數據更新到內存數據庫（redis，memcached），達到最大數即不接受該用戶的請求，同時這樣還可以利用到內存數據庫key在特定時間自動過期的特性。在php中可以使用APC，AlternativePHPCache (APC) 是一個開放自由的PHPopcode 緩存。它的目標是提供一個自由、 開放，和健全的框架用于緩存和優化PHP的中間代碼。在返回時設置X-Rate-Limit-Reset:當前時間段剩余秒數，APC的示例代碼如下：
7 錯誤處理
對于非法的，導致系統出錯的等請求都進行記錄，一些重要的操作，如登錄，注冊等都通過日志接口輸出展示。有一個統一的出錯接口，對于400系列和500系列的錯誤都有相應的錯誤碼和相關消息提示，如401：未授權；403：已經鑒權，但是沒有相應權限。如不識別的url:
,錯誤的請求參數
,不允許的方法：
，非法參數等。上面所說的都是單狀態碼，同時還有多狀態碼，表示部分成功，部分字符非法等。示例如下：
8 重要ID不透明處理
在系統一些敏感功能上，比如/user/1123 可獲取id=1123用戶的信息，為了防止字典遍歷攻擊，可對id進行url62或者uuid處理，這樣處理的id是唯一的，并且還是字符安全的。
9 其他注意事項
（1）請求數據，對于POST,DELETE方法中的數據都采用json格式，當然不是說rest架構不支持xml，由于xml太不好解析，對于大部分的應用json已經足夠，近一些的趨勢也是json越來越流行，并且json格式也不會有xml的一些安全問題，如xxe。使用json格式目前能防止掃描器自動掃描。 （2）返回數據統一編碼格式，統一返回類型，如Content-Type: application/json; charset=”UTF-8″ （3）在邏輯實現中，json解碼之后進行參數驗證或者轉義操作，第一步json格式驗證，第二步具體參數驗證基本上能防止大部分的注入問題了。 （4）在傳輸過程中，采用SSL保證傳輸安全。 （5）存儲安全，重要信息加密存儲，如認證信息hash保存。
總之，盡量使用SSL。
