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請求對應關係如下：
========== ===================== ========================
HTTP 方法 行為 示例
========== ===================== ========================
GET 獲取資源的信息 http://xx.com/api/orders
GET 獲取某個特定資源的信息 http://xx.com/api/orders/123
POST 創建新資源 http://xx.com/api/orders
PUT 更新資源 http://xx.com/api/orders/123
DELETE 刪除資源 http://xx.com/api/orders/123
========== ====================== =======================
對於請求的數據一般用json或者xml形式來表示，推薦使用json。
2，身份認證
身份認證包含很多種，有HTTP Basic，HTTP Digest，API KEY，Oauth，JWK等方式，下面簡單講解下：
2.1 HTTP Basic
REST由於是無狀態的傳輸，所以每一次請求都得帶上身份認證信息，身份認證的方式，身份認證的方式有很多種，第一種便是http basic，這種方式在客戶端要求簡單，在服務端實現也非常簡單，只需簡單配置apache等web服務器即可實現，所以對於簡單的服務來說還是挺方便的。但是這種方式安全性較低，就是簡單的將用戶名和密碼base64編碼放到header中。
base64編碼前：Basic admin:admin
base64編碼後：Basic YWRtaW46YWRtaW4=
放到Header中：Authorization: Basic YWRtaW46YWRtaW4=
正是因為是簡單的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頭中，具體的算法就如下圖
身份認證之後就是授權，根據不同的身份，授予不同的訪問權限。比如admin用戶，普通用戶，auditor用戶都是不同的身份。簡單的示例：
php
$roles = array(
'ADMIN'=>array(
'permit'=>array('/^((\/system\/(clouds|device)$/'), // 允許訪問哪些URL的正則表達式
'deny'=>array('/^(\/system\/audit)$/') // 禁止訪問哪些URL的正則表達式
),
'AUDIT'=>array(
'permit'=>array('/^(\/system\/audit)$/'),//允許訪問的URL正則表達式
'deny'=>array('/^((\/system\/(clouds|device).*)$/')
)
);
上述是垂直權限的處理，如果遇到了平行權限的問題，如用戶A獲取用戶B的身份信息或者更改其他用戶信息，對於這些敏感數據接口都需要加上對用戶的判斷，這一步一般都在具體的邏輯實現中實現。
4 URL過濾
在進入邏輯處理之前，加入對URL的參數過濾，如
/site/{num}/policy
限定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，Alternative PHP Cache (APC) 是一個開放自由的PHP opcode 緩存。它的目標是提供一個自由、 開放，和健全的框架用於緩存和優化PHP的中間代碼。在返回時設置X-Rate-Limit-Reset:當前時間段剩餘秒數，APC的示例代碼如下：
php
Route::filter('api.limit', function()
{
$key = sprintf('api:%s', Auth::user()->api_key);
// Create the key if it doesn't exist
Cache::add($key, 0, 60);
// Increment by 1
$count = Cache::increment($key);
// Fail if hourly requests exceeded
if ($count > Config::get('api.requests_per_hour'))
{
App::abort(403, 'Hourly request limit exceeded');
}
});
7 錯誤處理
對於非法的，導致系統出錯的等請求都進行記錄，一些重要的操作，如登錄，註冊等都通過日誌接口輸出展示。有一個統一的出錯接口，對於400系列和500系列的錯誤都有相應的錯誤碼和相關消息提示，如401：未授權；403：已經鑑權，但是沒有相應權限。如不識別的url:
{"result":"Invalid URL!"}
,錯誤的請求參數
{"result":"json format error"}
,不允許的方法：
{"result":"Method Not Allowed"}
，非法參數等。上面所說的都是單狀態碼，同時還有多狀態碼，表示部分成功，部分字符非法等。示例如下：
HTTP/1.1 207 Multi-Status
Content-Type: application/json; charset="UTF-8"
Content-Length: XXXX
{
"OPT_STATUS": 207
"DATA": {
"IP_ADDRESS": [{
"INTERFACE": "eth0",
"IP_LIST":[{
"IP": "192.168.1.1",
"MASK": "255.255.0.0",
"MULTI_STATUS": 200,
"MULTI_RESULT": "created successfully"
},{
"IP": "192.167.1.1",
"MASK": "255.255.0.0",
"MULTI_STATUS": 409,
"MULTI_RESULT": "invalid parameter"
}]
}]
},
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。
閱讀更多 IT生涯 的文章
