標籤：app 安全 url簽名
app和後端的通訊過程中，api請求有可能被別人截取或不小心泄露。那麼，怎麼保證api請求的安全呢？在這篇文章中，介紹一種常見的保證api請求安全的做法--url簽名。
1. url簽名詳解
在前一篇文章<15.app後端怎麼設計使用者登入方案>中，伺服器中驗證使用者名稱和密碼都正確後,產生一個隨機的不重複的token字串（例如"daf32da456hfdh"），在redis或memcache中維護一個映視表，建立token字串和使用者資訊的對應關係表，例如，把token字串"daf32da456hfdh"和使用者id"5"對應起來，伺服器把token字串返回給app用作身分識別驗證。
這個身分識別驗證是依賴於token字串。如果使用者泄露了自己的url, 那很大程度上token也被別人泄漏了。
怎麼防止token被泄露？不讓token在網路上傳輸就行。
注意，這個url簽名的方法是和前面＜15.app後端怎麼設計使用者登入方案＞緊密聯絡在一起的，沒看過前面一篇文章請先看。
(1) 伺服器中驗證使用者名稱和密碼都正確後，把token字串和使用者id都返回給用戶端，例如token字串"daf32da456hfdh"和使用者id"5"。
(2)假設api請求為"test.com/user/info", 通過token字串"daf32da456hfdh"產生md5簽名後: md5("test.com/user/info&token=daf32da456hfdh”)= C99DC0C22437AC275C08CE4A9708B25A
於是，api請求加上籤名和使用者標識後就是 ＂test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A＂
(3)伺服器接收到這個url後，用(2)的演算法產生簽名和sign參數對比，如果發現相等的話，就表示這個url是有有效,那就繼續執行這個api調用。
用上面的這個方法，就能避免token在api調用時泄露。
上面的方法還有一個問題，因為這個api請求＂test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A＂上沒有到期時間，假設別人拿到這個api的請求，就能反覆調用了。
改進方法是在傳遞的參數中增加時間戳記，當發現這個時間戳記離現在的時間已經很久了，就判斷這個url已經失效了。
但用時間戳記怎麼保證app的時間和伺服器的時間同步？在app每次啟動時和伺服器同步時間，然後在app內建一個時鐘，時間戳記在這個app的內部時鐘擷取，防止使用者修改了手機的時間導致時間不一致。
於是有了下面的改進方法：
(1)假設api請求為"test.com/user/info", 用token字串"daf32da456hfdh"和時間戳記產生md5簽名後: md5("test.com/user/info?userId=5&token=daf32da456hfdh×tamp=1425860757”)= C116161A6F430343B6CECF08562F1371
於是，api請求加上籤名和使用者標識後就是 ＂test.com/user/info?userId=5×tamp=1425860757&sign= C116161A6F430343B6CECF08562F1371＂
(2)伺服器接收到這個api請求，如果發現收到這個url請求的時間和time=1425860757相隔很久，就判斷出這個url是被別人截取來反覆調用了。如果時間合法，那就用(1)的演算法再判斷sign是否一致
2. url簽名的不足之處
url簽名有兩個缺點：
1.當使用者第一次登入後token是明文返回，有被截取的風險
2. url簽名只能保護token值卻沒法保護其他敏感性資料,例如，當使用者更新自己的個人資訊時，所有的資訊在傳輸過程中應該是被加密的
怎麼解決這兩個問題？使用下篇介紹的對稱式加密的演算法就可以了。
---------------------------------------------------------------------------------------------------------------------------
開啟連結 app後端系列文章總目錄 總目錄 ，能查看本人發表過的所有原創“app後端”文章。
【作者】曾健生
【QQ】190678908
【app後端qq群】254659220
【公眾號】 appbackend
【新浪微博】 @newjueqi
【部落格】http://blog.csdn.net/newjueqi
16.app後端如何保證通訊安全--url簽名
