接口安全性解析

針對
--->非開放性平臺
--->公司內部產品
 
接口特色彙總：
一、由於是非開放性的，因此全部的接口都是封閉的，只對公司內部的產品有效；
二、由於是非開放性的，因此OAuth那套協議是行不通的，由於沒有中間用戶的受權過程；
三、有點接口須要用戶登陸才能訪問；
四、有點接口不須要用戶登陸就可訪問；
 
針對以上特色，移動端與服務端的通訊就須要2把鑰匙，即2個token。
第一個token是針對接口的（api_token）；
第二個token是針對用戶的（user_token）；
 
先說第一個token（api_token）
 
它的職責是保持接口訪問的隱蔽性和有效性，保證接口只能給自家人用，怎麼作到？參考思路以下：
按服務器端和客戶端都擁有的共同屬性生成一個隨機串，客戶端生成這個串，服務器也按一樣算法生成一個串，用來校驗客戶端的串。
如今的接口基本是mvc模式，URL基本是restful風格，URL大致格式以下：
http://blog.snsgou.com/模塊名/控制器名/方法名?參數名1=參數值1&參數名2=參數值2&參數名3=參數值3
 
接口token生成規則參考以下：
api_token = md5 ('模塊名' + '控制器名' + '方法名' + '2013-12-18' + '加密密鑰') = 770fed4ca2aabd20ae9a5dd774711de2
其中的 
一、 '2013-12-18' 爲當天時間，
二、'加密密鑰' 爲私有的加密密鑰，手機端須要在服務端註冊一個「接口使用者」帳號後，系統會分配一個帳號及密碼，數據表設計參考以下：
字段名 字段類型 註釋
client_id varchar(20) 客戶端ID
client_secret varchar(20) 客戶端(加密)密鑰
（注：只列出了核心字段，其它的再擴展吧！！！）

 

再說第二個token（user_token）
 
它的職責是保護用戶的用戶名及密碼屢次提交，以防密碼泄露。
若是接口須要用戶登陸，其訪問流程以下：
一、用戶提交「用戶名」和「密碼」，實現登陸（條件容許，這一步最好走https）；
二、登陸成功後，服務端返回一個 user_token，生成規則參考以下：
user_token = md5('用戶的uid' + 'Unix時間戳') = etye0fgkgk4ca2aabd20ae9a5dd77471fgf
服務端用數據表維護user_token的狀態，表設計以下：
字段名 字段類型 註釋
user_id int 用戶ID
user_token varchar(36) 用戶token
expire_time int 過時時間（Unix時間戳）
（注：只列出了核心字段，其它的再擴展吧！！！）
服務端生成 user_token 後，返回給客戶端（本身存儲），客戶端每次接口請求時，若是接口須要用戶登陸才能訪問，則須要把 user_id 與 user_token 傳回給服務端，服務端接受到這2個參數後，須要作如下幾步：
一、檢測 api_token的有效性；
二、刪除過時的 user_token 表記錄；
三、根據 user_id，user_token 獲取表記錄，若是表記錄不存在，直接返回錯誤，若是記錄存在，則進行下一步；
四、更新 user_token 的過時時間（延期，保證其有效期內連續操做不掉線）；
五、返回接口數據；
 
接口用例以下：
 
一、發佈日誌
URL：  http://blog.snsgou.com/blog/Index/addBlog?client_id=wt3734wy636dhd3636sr5858t6&api_token=880fed4ca2aabd20ae9a5dd774711de2&user_token=etye0fgkgk4ca2aabd20ae9a5dd77471fgf&user_id=12
請求方式：  POST
POST參數：title=我是標題&content=我是內容
返回數據：
{
      'code' => 1, // 1:成功 0:失敗
      'msg' => '操做成功' // 登陸失敗、無權訪問
      'data' => []
}

對於 api_token 的校驗，其安全性還可再加強：

 

加強地方一：

 

再增長2張表，一個接口表，一個受權表，設計參考以下：

接口表

字段名	字段類型	註釋
api_id	int	接口ID
api_name	varchar(120)	接口名，以"/"做爲分割線，如 blog/Index/addBlog
api_domain	varchar(256)	所屬領域
is_enabled	tinyint(1)	是否可用  1:可用 0:不可用
add_time	int	添加時間（戳）

（注：只列出了核心字段，其它的再擴展吧！！！）

 

受權表

字段名	字段類型	註釋
client_id	int	客戶端ID
api_id	int	api編號
api_name	varchar(120)	接口名，以"/"做爲分割線，如 blog/Index/addBlog
is_enabled	tinyint(1)	是否可用  1:可用 0:不可用
add_time	int	添加時間（戳）
expire_time	int	過時時間（戳）

（注：只列出了核心字段，其它的再擴展吧！！！）

 

執行過程以下：

一、移動端與服務端生成的 api_token 進行對比，若是不相等，則直接返回錯誤，不然，進入下一步；

二、根據接口URL，組裝 api_name，再加上客戶端傳回的 client_id 爲參數，查找 「受權表」記錄，若是記錄存在，且有效（是否可用，是否過時），則表示權限驗證經過，返回接口數據，不然返回錯誤信息；

 

加強地方二：

 

對於一些很特殊的接口，怎麼特殊，哪些算特殊，我也不知道，總而言之，就是感受http請求有可能被劫取，傳遞參數有可能被竄改等狀況，仍是舉個例子來講吧：

有個直接轉帳接口，頁面上 我輸入的是5元，表示我要給對方某某轉帳5元，結果在http傳遞過程當中，被人劫取並竄改爲了 10000元，並且入帳對象改爲了「黑客」的帳號，那不是虧大發了，思考了一下，應該有2種方案解決這個問題，

 

方案一：走https，這個就很少說，比較公認的安全機制；

方案二：走數字簽名，實現原理以下：

 

一個http請求，假如須要傳遞以下3個參數

 

參數名1=參數值1

參數名2=參數值2

參數名3=參數值3

 

咱們能夠再追加一個參數，該參數的名爲 identity_key （名字是什麼不重要），該參數的值爲 加密密鑰')