不要急,源代碼分享在最底部,先問大家一個問題,你在寫開放的API介面時是如何保證數據的安全性的?先來看看有哪些安全性問題在開放的api介面中,我們通過http Post或者Get方式請求伺服器的時候,會面臨著許多的安全性問題,例如: 1. 請求來源(身份)是否合法? 2. 請求參數被篡改? 3. 請... ...
不要急,源代碼分享在最底部,先問大家一個問題,你在寫開放的API介面時是如何保證數據的安全性的?先來看看有哪些安全性問題在開放的api介面中,我們通過http Post或者Get方式請求伺服器的時候,會面臨著許多的安全性問題,例如:
- 1. 請求來源(身份)是否合法?
- 2. 請求參數被篡改?
- 3. 請求的唯一性(不可複製)
為了保證數據在通信時的安全性,我們可以採用參數簽名的方式來進行相關驗證。
案列分析
我們通過給某 [移動端(app)] 寫 [後臺介面(api)] 的案例進行分析:
客戶端: 以下簡稱app
後臺介面:以下簡稱api
我們通過app查詢產品列表這個操作來進行分析:
app中點擊查詢按鈕==》調用api進行查詢==》返回查詢結果==>顯示在app中
上代碼啦 -_-!
一、不進行驗證的方式
api查詢介面:
app調用:http://api.test.com/getproducts?參數1=value1.......
如上,這種方式簡單粗暴,通過調用getproducts方法即可獲取產品列表信息了,但是 這樣的方式會存在很嚴重的安全性問題,沒有進行任何的驗證,大家都可以通過這個方法獲取到產品列表,導致產品信息泄露。
那麼,如何驗證調用者身份呢?如何防止參數被篡改呢?
二、MD5參數簽名的方式
我們對api查詢產品介面進行優化:
1. 給app分配對應的key、secret
2. Sign簽名,調用API 時需要對請求參數進行簽名驗證,簽名方式如下:
a. 按照請求參數名稱將所有請求參數按照字母先後順序排序得到:keyvaluekeyvalue...keyvalue 字元串如:將arong=1,mrong=2,crong=3 排序為:arong=1, crong=3,mrong=2 然後將參數名和參數值進行拼接得到參數字元串:arong1crong3mrong2。
b. 將secret加在參數字元串的頭部後進行MD5加密 ,加密後的字元串需大寫。即得到簽名Sign
新api介面代碼:
app調用:http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&參數1=value1&參數2=value2.......
註:secret 僅作加密使用, 為了保證數據安全請不要在請求參數中使用。
如上,優化後的請求多了key和sign參數,這樣請求的時候就需要合法的key和正確簽名sign才可以獲取產品數據。這樣就解決了身份驗證和防止參數篡改問題,如果請求參數被人拿走,沒事,他們永遠也拿不到secret,因為secret是不傳遞的。再也無法偽造合法的請求。
但是...這樣就夠了嗎?細心的同學可能會發現,如果我獲取了你完整的鏈接,一直使用你的key和sign和一樣的參數不就可以正常獲取數據了...-_-!是的,僅僅是如上的優化是不夠的
請求的唯一性:
為了防止別人重覆使用請求參數問題,我們需要保證請求的唯一性,就是對應請求只能使用一次,這樣就算別人拿走了請求的完整鏈接也是無效的。
唯一性的實現:在如上的請求參數中,我們加入時間戳 :timestamp(yyyyMMddHHmmss),同樣,時間戳作為請求參數之一,也加入sign演算法中進行加密。
新的api介面:
app調用:
http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35×tamp=201603261407&參數1=value1&參數2=value2.......
如上,我們通過timestamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈接也是無效的。
Sign簽名安全性分析:
通過上面的案例,我們可以看出,安全的關鍵在於參與簽名的secret,整個過程中secret是不參與通信的,所以只要保證secret不泄露,請求就不會被偽造。
總結
上述的Sign簽名的方式能夠在一定程度上防止信息被篡改和偽造,保障通信的安全,這裡使用的是MD5進行加密,當然實際使用中大家可以根據實際需求進行自定義簽名演算法,比如:RSA,SHA等。
相關方法源碼分享:
源碼已托管至碼雲:https://git.oschina.net/daimali/Daimali.ISV
來源:http://www.daimali.com/index.php/2016/04/27/241/