app接口安全性設計淺析

之前面試的時候被問到這個，app接口安全性，這個因不同的場景，要考慮的情況也不一樣。下面把自己的見聞和思考寫一下吧。

（1）簽名與加密

這個一般接口中會有的，典型的有MD5和AES。

一個接口形式是：

http://test.com/api/test.html?userId=9&timestamp=14324344&randomString=532sgdfg&sgin=GGERH5363463

sign=MD5(userId+timestamp+randomString)

timestamp 一般用來給伺服器驗證請求時間區間，5-30分鐘不等。

randomString 作為簽名的參數作用不大。

這個由于都是明文的，一般都能猜到這麼簽名。是以，會加一個鹽，

sign=MD5(userId+timestamp+randomString+salt1)

salt1為用戶端與服務端保留，是個常量。一般不在接口中傳遞。

有人說，将app放進模拟器或者反編譯，就能獲得salt1。

是以，光是一個常量是不夠的，還要一個動态量。這個動态量就是token，一般在每次使用者登入後，會獲得一個重新整理的token，UUID生成的。

http://test.com/api/test.html?userId=9&timestamp=14324344&randomString=532sgdfg&token=dfhfjgdfsgsdg&sgin=GGERH5363463

sign=MD5(userId+timestamp+randomString+salt1+token)

token的有效期一般為12小時或24小時。

這樣，用戶端的請求，服務端先驗證token，再驗證sign。

以上的處理，效果如下：

1. 較長時間段前的請求連結無效；
2. 不良使用者把篡改的請求連結在浏覽器中操作無效；
3. 每隔一段時間，有一個登入的驗證。

但以上也看出，token驗證的難度并不大，畢竟token的有效時間有十幾個小時。

是以，本人設計添加了一個動态量，叫token2。

這個token2的有效期更短，一般在幾十秒，假定30秒-45秒。也可以更短。

它由token1和salt1生成，不在用戶端保留，每次接口請求都要從伺服器拿。擷取token2中也會用到AES加密。

然後把token2也放到sign簽名中（接口中不傳）：

sign=MD5(userId+timestamp+randomString+salt1+token+token2)

服務端原來驗證token改為驗證token2了，這樣，如果不是極端情況，保證了2點：

1. 用戶端的請求都是由APP端發出的；

2. 每次請求的有效期隻有30-45秒。

   設定30-45秒是考慮到wap端的使用者請求，點選，浏覽的平均時間會稍微比app端慢一些。如果在一個網頁，使用者遲疑了一下再點選，發現連結失效，需要重新退回上個頁面，不是太好，是以設定幾十秒。

還有RSA也能簽名。

當然，除了MD5，還有AES加密。AES也有加salt加密。由于是對稱型，AES可以多次加密。可是隻要salt知道，也能容易猜到，本人一般配合MD5使用。

（2）https

這個是要證書的，要錢的。本人還沒做過。

（3）第三方授權。

大公司用的多，擷取騰訊，新浪使用者資訊用這種方式。其中關鍵，是一個code和token，也是動态的，安全性，比以上介紹的要強一些。