HTTP API 接口簽名驗證

  • AccessKey&SecretKey (開放平臺)

  • 請求身份

  • 防止篡改

  • 重放攻擊

  • 實現(xiàn)

  • Token&AppKey(APP)

  • Token身份驗證

  • Token+AppKey簽名驗證

  • 實現(xiàn)

  • 后續(xù)請求

接口安全問題

  • 請求身份是否合法?
  • 請求參數(shù)是否被篡改?
  • 請求是否唯一?

AccessKey&SecretKey (開放平臺)

請求身份

為開發(fā)者分配AccessKey(開發(fā)者標識,確保唯一)和SecretKey(用于接口加密,確保不易被窮舉,生成算法不易被猜測)。

防止篡改

參數(shù)簽名

  • 按照請求參數(shù)名的字母升序排列非空請求參數(shù)(包含AccessKey),使用URL鍵值對的格式(即key1=value1&key2=value2…)拼接成字符串stringA;
  • 在stringA最后拼接上Secretkey得到字符串stringSignTemp;
  • 對stringSignTemp進行MD5運算,并將得到的字符串所有字符轉(zhuǎn)換為大寫,得到sign值。

請求攜帶參數(shù)AccessKey和Sign,只有擁有合法的身份AccessKey和正確的簽名Sign才能放行。這樣就解決了身份驗證和參數(shù)篡改問題,即使請求參數(shù)被劫持,由于獲取不到SecretKey(僅作本地加密使用,不參與網(wǎng)絡(luò)傳輸),無法偽造合法的請求。

重放攻擊

雖然解決了請求參數(shù)被篡改的隱患,但是還存在著重復(fù)使用請求參數(shù)偽造二次請求的隱患。

timestamp+nonce方案

nonce指唯一的隨機字符串,用來標識每個被簽名的請求。通過為每個請求提供一個唯一的標識符,服務(wù)器能夠防止請求被多次使用(記錄所有用過的nonce以阻止它們被二次使用)。

然而,對服務(wù)器來說永久存儲所有接收到的nonce的代價是非常大的。可以使用timestamp來優(yōu)化nonce的存儲。

假設(shè)允許客戶端和服務(wù)端最多能存在15分鐘的時間差,同時追蹤記錄在服務(wù)端的nonce集合。當有新的請求進入時,首先檢查攜帶的timestamp是否在15分鐘內(nèi),如超出時間范圍,則拒絕,然后查詢攜帶的nonce,如存在已有集合,則拒絕。否則,記錄該nonce,并刪除集合內(nèi)時間戳大于15分鐘的nonce(可以使用redis的expire,新增nonce的同時設(shè)置它的超時失效時間為15分鐘)。

實現(xiàn)

請求接口:http://api.test.com/test?name=hello&home=world&work=java

客戶端

  • 生成當前時間戳timestamp=now和唯一隨機字符串nonce=random
  • 按照請求參數(shù)名的字母升序排列非空請求參數(shù)(包含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并轉(zhuǎn)換為大寫sign=MD5(stringSignTemp).toUpperCase();
  • 最終請求http://api.test.com/test?name=hello&home=world&work=java×tamp=now&nonce=nonce&sign=sign;

服務(wù)端

Token&AppKey(APP)

在APP開放API接口的設(shè)計中,由于大多數(shù)接口涉及到用戶的個人信息以及產(chǎn)品的敏感數(shù)據(jù),所以要對這些接口進行身份驗證,為了安全起見讓用戶暴露的明文密碼次數(shù)越少越好,然而客戶端與服務(wù)器的交互在請求之間是無狀態(tài)的,也就是說,當涉及到用戶狀態(tài)時,每次請求都要帶上身份驗證信息。

Token身份驗證

  • 用戶登錄向服務(wù)器提供認證信息(如賬號和密碼),服務(wù)器驗證成功后返回Token給客戶端;
  • 客戶端將Token保存在本地,后續(xù)發(fā)起請求時,攜帶此Token;
  • 服務(wù)器檢查Token的有效性,有效則放行,無效(Token錯誤或過期)則拒絕。
  • 安全隱患:Token被劫持,偽造請求和篡改參數(shù)。

Token+AppKey簽名驗證

與上面開發(fā)平臺的驗證方式類似,為客戶端分配AppKey(密鑰,用于接口加密,不參與傳輸),將AppKey和所有請求參數(shù)組合成源串,根據(jù)簽名算法生成簽名值,發(fā)送請求時將簽名值一起發(fā)送給服務(wù)器驗證。

這樣,即使Token被劫持,對方不知道AppKey和簽名算法,就無法偽造請求和篡改參數(shù)。再結(jié)合上述的重發(fā)攻擊解決方案,即使請求參數(shù)被劫持也無法偽造二次重復(fù)請求。

實現(xiàn)

登陸和退出請求

登陸和退出流程

后續(xù)請求

客戶端

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

服務(wù)端

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容