問題描述

服務(wù)端提供各種功能接口供客戶端調(diào)用，那么怎樣才能確保請求是來自合法的客戶端，而不是非法的請求呢？

問題解答

驗證token，或者服務(wù)端用OAuth2框架

你是如何定義合法和非法的？在SSO框架下，有token就是橫著走，如果是第三方肯定需要appid和appsecret，需要授權(quán)的話還要帶上AccessToken，這樣也是橫著走，最簡單的是寫一個IP攔截器，只允許信任IP通過，但是是用于內(nèi)部互相調(diào)用的高級別攔截了，一般來說對方提供了token或appsecret，基本上都算是合法的吧？

在設(shè)計API時，要保證RESTful API的安全性，主要考慮三個大方面：

1.對受限資源的登錄授權(quán)2.對請求做身份認(rèn)證3.對敏感數(shù)據(jù)進(jìn)行加密

一、受限資源的登錄授權(quán)此流程不是本文重點，不贅述，基本流程如下：

客戶端提交賬號信息（用戶名+密碼）到服務(wù)端

服務(wù)端驗證成功，返回AccessToken給客戶端存儲3.訪問受限資源時，客戶端帶入AccessToken就可訪問。

二、請求認(rèn)證如果不對請求進(jìn)行簽名認(rèn)證，那么可以簡單的通過fiddler等工具輕易抓包拿到數(shù)據(jù)，并進(jìn)行篡改，提交，大規(guī)模批量調(diào)用，則會使系統(tǒng)產(chǎn)生大量垃圾數(shù)據(jù)，系統(tǒng)資源被大量消耗，甚至無法正常使用（另說，當(dāng)然可以通過GateWay進(jìn)行限流），因而我們需要對請求進(jìn)行簽名認(rèn)證。

URL格式URL:schema://domain/path?query&imei×tamp&sign

參數(shù)說明簽名方法sign=signature(path?query&imei×tamp&SIGN_KEY)

驗證過程認(rèn)證邏輯1、初始時，服務(wù)端存有各App版本的SIGN_KEY，客戶端存有對應(yīng)版本的SIGN_KEY2、當(dāng)要發(fā)送請求之前，通過簽名方法加密，得到一個sign3、發(fā)送請求的時候，連同sign一起發(fā)送給服務(wù)器端4、服務(wù)器端首先驗證時間戳timestamp是否有效，比如是服務(wù)器時間戳5分鐘之前的請求視為無效；5、然后取對應(yīng)版本的SIGN_KEY驗證sign是否合法6、為了防止重放攻擊，需要檢查sign是否在redis中存儲，如不存在則存入redis（緩存5分鐘）

如何防止數(shù)據(jù)篡改這里通過簽名參數(shù)中包含原有請求的所有參數(shù)，改動任意參數(shù)，sign值都會不同，因此無法篡改。

如何防止重放攻擊由于簽名算法中還有imei(設(shè)備唯一Id)、timestamp參數(shù)，且簽名算法為不可逆算法（如md5或sha1），因而對于正常的每個請求sign值不會重復(fù)。此時服務(wù)端可以存儲5分鐘的sign值，來做重放攻擊時的驗證過濾，超過5分鐘的請求則直接被timestamp校驗過濾。

總結(jié)如此便實現(xiàn)了請求認(rèn)證，防止數(shù)據(jù)篡改，重放攻擊，但是需要確保App密鑰(SIGN_KEY)的安全保存，其優(yōu)點是容易理解與實現(xiàn)，缺點是需要承擔(dān)安全保存密鑰和定期更新密鑰的負(fù)擔(dān)。

三、敏感據(jù)加密1)、部署SSL基礎(chǔ)設(shè)施（即HTTPS），敏感數(shù)據(jù)的傳輸全部基于SSL。2)、僅對部分敏感數(shù)據(jù)做加密（例如賬號+密碼），并加入某種隨機(jī)數(shù)作為加密鹽，以防范數(shù)據(jù)被篡改。

我們用的RSA加密算法,請求數(shù)據(jù)的參數(shù)均轉(zhuǎn)成json然后用服務(wù)器RSA證書對json進(jìn)行加密,http請求就可以了,服務(wù)端私鑰解密

使用oauth2或者類似的token之類的