app介面安全性

標籤：

針對
--->非開放性平台
--->公司內部產品
 
介面特點匯總：
1、因為是非開放性的，所以所有的介面都是封閉的，只對公司內部的產品有效；
2、因為是非開放性的，所以OAuth那套協議是行不通的，因為沒有中間使用者的授權過程；
3、有點介面需要使用者登入才能訪問；
4、有點介面不需要使用者登入就可訪問；
 
針對以上特點，移動端與服務端的通訊就需要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
其中的
1、 ‘2013-12-18‘ 為當天時間，
2、‘加密金鑰‘ 為私人的加密金鑰，手機端需要在服務端註冊一個“介面使用者”帳號後，系統會分配一個帳號及密碼，資料表設計參考如下：
欄位名 欄位類型 注釋
client_id varchar(20) 用戶端ID
client_secret varchar(20) 用戶端(加密)密鑰
（註：只列出了核心欄位，其它的再擴充吧！！！）
 
服務端介面校正，PHP實現流程如下：

<?php// 1、擷取 GET參數 值$module = $_GET[‘mod‘];$controller = $_GET[‘ctl‘]$action = $_GET[‘act‘];$client_id = $_GET[‘client_id‘];$api_token = $_GET[‘‘api_token];// 2、根據用戶端傳過來的 client_id ，查詢資料庫，擷取對應的 client_secret$client_secret = getClientSecretById($client_id);// 3、服務端重建一份 api_token$api_token_server = md5($module . $controller . $action .  date(‘Y-m-d‘, time()) .  $client_secret);// 4、用戶端傳過來的 api_token 與服務端產生的 api_token 進行校對，如果不相等，則表示驗證失敗if ($api_token != $api_token_server) { exit(‘access deny‘);  // 拒絕訪問}// 5、驗證通過，返回資料給用戶端//。。。?>

　　

 

 
再說第二個token（user_token）
 
它的職責是保護使用者的使用者名稱及密碼多次提交，以防密碼泄露。
如果介面需要使用者登入，其訪問流程如下：
1、使用者提交“使用者名稱”和“密碼”，實現登入（條件允許，這一步最好走https）；
2、登入成功後，服務端返回一個 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個參數後，需要做以下幾步：
1、檢測 api_token的有效性；
2、刪除到期的 user_token 表記錄；
3、根據 user_id，user_token 擷取表記錄，如果表記錄不存在，直接返回錯誤，如果記錄存在，則進行下一步；
4、更新 user_token 的到期時間（延期，保證其有效期間內連續操作不掉線）；
5、返回介面資料；
 
介面用例如下：
 
1、發布日誌
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	到期時間（戳）

（註：只列出了核心欄位，其它的再擴充吧！！！）

 

執行過程如下：

1、移動端與服務端產生的 api_token 進行對比，如果不相等，則直接返回錯誤，否則，進入下一步；

2、根據介面URL，組裝 api_name，再加上用戶端傳回的 client_id 為參數，尋找 “授權表”記錄，如果記錄存在，且有效（是否可用，是否到期），則表示許可權驗證通過，返回介面資料，否則返回錯誤資訊；

 

增強地方二：

 

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

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

 

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

方案二：走數位簽章，實現原理如下：

 

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

 

參數名1=參數值1

參數名2=參數值2

參數名3=參數值3

 

我們可以再追加一個參數，該參數的名為 identity_key （名字是什麼不重要），該參數的值為 加密金鑰‘)

 

服務端接到參數後，再按相同的加密規則重建一份 identity_key，服務端的identity_key和用戶端的identity_key 進行校對，如果不相等，表示被竄改過，接下來怎麼操作，自己看著辦吧！

 文章轉載自：http://blog.snsgou.com/post-766.html
 

app介面安全性