移動互聯(lián)時代，APP項目開發(fā)需求項目市場越來越大，很多客戶都希望對自己即將需要的APP平臺有所了解，深圳APP開發(fā)公司在前面關(guān)于APP制作后臺搭建文章中介紹了很多方法，今天我們接前面相關(guān)文章將我們APP開發(fā)工程師對于后臺制作“APP通信安全”進(jìn)行交流分享。
APP開發(fā)怎樣注意App通信安全
在前篇相關(guān)文章中說過用戶驗證方案”中API請求的token有可能泄露，為了保證App通信的安全．我們可以采用下面介紹的保證App通信愛全的方法
（1）URL簽名
在前文“用戶驗證方案”中，在App后臺中驗證用戶名和密碼都正確后，生成一個隨機(jī)的不重復(fù)的token字符串(例如“daf32da456hfdh”)，在Redis或Melncache中建立token字符串和用戶信息的對應(yīng)關(guān)系，例如把tokeu字符串“daf32da456hfdh”和用戶id“5”對應(yīng)，App后臺把token字符串返回給App以作身份驗證。
身份驗證是依賴于tokeu字符串。如果用戶泄露了自己的URL，那很大程度上tokeu也被別人泄露了。因此不在網(wǎng)絡(luò)上傳輸token就能在很大程度上防止token泄露。不在網(wǎng)絡(luò)上傳輸token的方案稱為URL簽名，過程如下：
注意：URL5名的萬法是和上節(jié)“APP用尸驗證方案”緊密聯(lián)系，各位APP開發(fā)愛好者在閱讀本節(jié)前請務(wù)必閱讀上一節(jié)“用戶驗證方案”
(1) App后臺中用戶名和密碼驗證正確后，把token字符串和用戶信息部返回給App，例如token字符串“daf32da456hfdh”和用戶id“5”Redis中除了維護(hù)token字符串和用戶信息的對應(yīng)關(guān)系，還要維護(hù)用戶id和token的對應(yīng)關(guān)系，以方便后面App后臺驗證URL簽名時快速查找。
(2)假設(shè)API請求為test. com／user/info , App用token產(chǎn)符串“daf32da456hfdh’和URL的md5值作為URL簽名tsign。
于是API請求加上URL簽名sign和用戶id后如下所示。
這樣token就不需要附在URL。
(3) App后臺接收到這個URL后，用(2)所描述的算法生成簽名和sign參數(shù)對比，如果發(fā)現(xiàn)相等就表示驗證通過，繼續(xù)執(zhí)行這個API的其
他邏輯。
URI,簽名的驗證流程如圖3 4所示
。
上述URL簽名方法有個問題：因為API請求“test. com/user/iufo?userid=5&sigu=6dac4026135a123a3cf809alfibfid2a沒有過期時間，假設(shè)黑客截獲了這個API請求的URL．就能反復(fù)調(diào)用這個URL。改進(jìn)方法是在傳遞的參數(shù)中增加時間戳，當(dāng)App后臺發(fā)現(xiàn)這個時間戳相隔當(dāng)前時間很久的，就判斷這個URL已經(jīng)失效
App端使用時間戳的一個問題是：App端的時間有可能和App后臺的時間不一致。保證App端時間和App后臺時間同步的方法為：App每次啟動時通過API獲取App后臺的時間，保存App端時間和App后臺的時間差，以后App端用這個時間差調(diào)整其生成的時間戳。例如，某刻API獲取App后臺的時間是1444692778，App端時間是1444692775，兩者的時間差是3。當(dāng)App在本地時司l425860754準(zhǔn)備同App后臺發(fā)送API請求時，加上時間差3，即可得到App后臺的時間為1425860754+3:1425860757，1425860757即為參數(shù)中傳遞的時間戳。根據(jù)以上的討論得到下面的改進(jìn)方法
（4）假設(shè)API請求為test. com／user/info，用toke字符串daf32da456hfdh和時間戳1425860757生成的md5值URL簽名sign。
（5） App后臺接收到這個API請求，如果收sicjn=md5("test.c_.m/user/inf_,?userid=5S,t:Len=dafn:da45,hfdhS,timfstamp=14:58e07s7")=rllEl01P.6F4n034?
EoC_ECF0850:Fin71到該API請求的時間和URL上時間戳的值1425860757比較（例如相隔了30s），可能意味著這個URL是黑客截取的用戶請求，被黑客用來反復(fù)調(diào)用了，因此為了安全性，應(yīng)該拒絕這個URL后續(xù)的業(yè)務(wù)邏輯。App后臺認(rèn)為時間合法，那就繼續(xù)使用(
4)的算法判斷sign是否致。
·當(dāng)用戶登錄后，App后臺返回給App的信息（包括token等個人信息）沒加密，有被截取的風(fēng)險。
·URL簽名只能保護(hù)token值不泄露，但沒法保護(hù)其他敏感數(shù)據(jù)，例如，當(dāng)用戶更新自己的個人信息時，所有的信息在傳輸過程中應(yīng)該被加密。
·URL被黑客截獲后還是能在段時間內(nèi)調(diào)用（假設(shè)App后臺認(rèn)為有效的間隔時間是30s）。
使用前文AES對稱加密”可以解決上面提出的3個問題。深圳APP開發(fā)公司博納網(wǎng)絡(luò)編輯整理。關(guān)于URL簽名流程以及注意事項我們今天就分享到這里。在后期的文章中我們會對AES對稱加密方法經(jīng)驗進(jìn)行分享。
