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以阻止它們被二次使用)。
實現
請求介面: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";
- 拼接金鑰SecretKey
stringSignTemp="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
介面安全問題
-
請求身份是否合法?
-
請求引數是否被篡改?
-
請求是否唯一?
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";
- 拼接金鑰SecretKey
stringSignTemp="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