Java生鮮電商平臺-開放API介面簽名驗證(小程式/APP)-有解無憂

Java生鮮電商平臺-開放API介面簽名驗證(小程式/APP)

說明：在實際的生鮮業務中，不可避免的需要對外提供api介面給外部進行呼叫. 這里就有一個介面安全的問題需要溝通了，下面是干貨:

介面安全問題

請求身份是否合法？
請求引數是否被篡改？
請求是否唯一？

AccessKey&SecretKey （開放平臺）

請求身份

為開發者分配AccessKey（開發者標識，確保唯一）和SecretKey（用于介面加密，確保不易被窮舉，生成演算法不易被猜測），

防止篡改

引數簽名

按照請求引數名的字母升序排列非空請求引數（包含AccessKey），使用URL鍵值對的格式（即key1=value1&key2=value2…）拼接成字串stringA；
在stringA最后拼接上Secretkey得到字串stringSignTemp；
對stringSignTemp進行MD5運算，并將得到的字串所有字符轉換為大寫，得到sign值，

請求攜帶引數AccessKey和Sign，只有擁有合法的身份AccessKey和正確的簽名Sign才能放行，這樣就解決了身份驗證和引數篡改問題，即使請求引數被劫持，由于獲取不到SecretKey（僅作本地加密使用，不參與網路傳輸），無法偽造合法的請求，

重放攻擊

雖然解決了請求引數被篡改的隱患，但是還存在著重復使用請求引數偽造二次請求的隱患，timestamp+nonce方案nonce指唯一的隨機字串，用來標識每個被簽名的請求，通過為每個請求提供一個唯一的識別符號，服務器能夠防止請求被多次使用（記錄所有用過的nonce以阻止它們被二次使用），然而，對服務器來說永久存盤所有接收到的nonce的代價是非常大的，可以使用timestamp來優化nonce的存盤，假設允許客戶端和服務端最多能存在15分鐘的時間差，同時追蹤記錄在服務端的nonce集合，當有新的請求進入時，首先檢查攜帶的timestamp是否在15分鐘內，如超出時間范圍，則拒絕，然后查詢攜帶的nonce，如存在已有集合，則拒絕，否則，記錄該nonce，并洗掉集合內時間戳大于15分鐘的nonce（可以使用redis的expire，新增nonce的同時設定它的超時失效時間為15分鐘），

實作

請求介面：http://api.test.com/test?name=hello&home=world&work=java客戶端

生成當前時間戳timestamp=now和唯一隨機字串nonce=random
按照請求引數名的字母升序排列非空請求引數（包含AccessKey)stringA="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random";
拼接密鑰SecretKeystringSignTemp="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random&SecretKey=secret";
MD5并轉換為大寫sign=MD5(stringSignTemp).toUpperCase();
最終請求http://api.test.com/test?name=hello&home=world&work=java×tamp=now&nonce=nonce&sign=sign;

服務端

Token&AppKey（APP）

在APP開放API介面的設計中，由于大多數介面涉及到用戶的個人資訊以及產品的敏感資料，所以要對這些介面進行身份驗證，為了安全起見讓用戶暴露的明文密碼次數越少越好，然而客戶端與服務器的互動在請求之間是無狀態的，也就是說，當涉及到用戶狀態時，每次請求都要帶上身份驗證資訊，

Token身份驗證

用戶登錄向服務器提供認證資訊（如賬號和密碼），服務器驗證成功后回傳Token給客戶端；
客戶端將Token保存在本地，后續發起請求時，攜帶此Token；
服務器檢查Token的有效性，有效則放行，無效（Token錯誤或過期）則拒絕，
安全隱患：Token被劫持，偽造請求和篡改引數，

Token+AppKey簽名驗證

與上面開發平臺的驗證方式類似，為客戶端分配AppKey（密鑰，用于介面加密，不參與傳輸），將AppKey和所有請求引陣列合成源串，根據簽名演算法生成簽名值，發送請求時將簽名值一起發送給服務器驗證，這樣，即使Token被劫持，對方不知道AppKey和簽名演算法，就無法偽造請求和篡改引數，再結合上述的重發攻擊解決方案，即使請求引數被劫持也無法偽造二次重復請求，

實作

登陸和退出請求

登陸和退出流程

后續請求

客戶端

和上述開放平臺的客戶端行為類似，把AccessKey改為token即可，

服務端

總結: 這個是目前第三方資料介面互動程序中常用的一些引數與使用示例，希望對大家有點幫助，

當然如果為了保證更加的安全，可以加上RSA,RSA2，AES等等加密方式，保證了資料的更加的安全，但是唯一的缺點是加密與解密比較耗費CPU的資源.

共同學習QQ群：793305035