RESTFUL API 安全設計指南
0x01 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。
0x02 身份認證
身份認證包含很多種，有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頭中，具體的算法就如下圖
0x03 授權
身份認證之后就是授權，根據不同的身份，授予不同的訪問權限。比如admin用戶，普通用戶，auditor用戶都是不同的身份。簡單的示例：
|
1
2
3
4
5
6
7
8
9
10
|
$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的身份信息或者更改其他用戶信息，對于這些敏感數據接口都需要加上對用戶的判斷，這一步一般都在具體的邏輯實現中實現。
0x04 URL過濾
在進入邏輯處理之前，加入對URL的參數過濾，如/site/{num}/policy 限定num位置為整數等，如果不是參數則直接返回非法參數，設定一個url清單，不在不在url清單中的請求直接拒絕，這樣能防止開發中的api泄露。rest api接口一般會用到GET,POST,PUT,DELETE,未實現的方法則直接返回方法不允許，對于POST，PUT方法的數據采用json格式，并且在進入邏輯前驗證是否json，不合法返回json格式錯誤。
0x05 重要功能加密傳輸
第一步推薦SSL加密傳輸，同時對于系統中重要的功能做加密傳輸，如證書，一些數據，配置的備份功能，同時還得確保具備相應的權限，這一步會在授權中涉及。
0x06 速率限制
請求速率限制，根據api_key或者用戶來判斷某段時間的請求次數，將該數據更新到內存數據庫（redis，memcached），達到最大數即不接受該用戶的請求，同時這樣還可以利用到內存數據庫key在特定時間自動過期的特性。在php中可以使用APC，Alternative PHP Cache (APC) 是一個開放自由的PHP opcode 緩存。它的目標是提供一個自由、 開放，和健全的框架用于緩存和優化PHP的中間代碼。在返回時設置X-Rate-Limit-Reset:當前時間段剩余秒數，APC的示例代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
Route::filter('api.limit', function(){$key = sprintf('api:%s', Auth::user()->api_key);// Create the key if it doesn't existCache::add($key, 0, 60);// Increment by 1$count = Cache::increment($key);// Fail if hourly requests exceededif ($count > Config::get('api.requests_per_hour')){App::abort(403, 'Hourly request limit exceeded');}}); |
0x07 錯誤處理
對于非法的，導致系統出錯的等請求都進行記錄，一些重要的操作，如登錄，注冊等都通過日志接口輸出展示。有一個統一的出錯接口，對于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"
}]
}]
},
0x08 重要ID不透明處理
在系統一些敏感功能上，比如/user/1123 可獲取id=1123用戶的信息，為了防止字典遍歷攻擊，可對id進行url62或者uuid處理，這樣處理的id是唯一的，并且還是字符安全的。
0x09 其他注意事項
（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。
文章列表
留言列表
