api介面簽名驗證 MD5

2022-04-04 05:05:13 字數 1650 閱讀 6380

**  

你在寫開放的api介面時是如何保證資料的安全性的?先來看看有哪些安全性問題在開放的api介面中,我們通過http post或者get方式請求伺服器的時候,會面臨著許多的安全性問題,例如:

請求**(身份)是否合法?

請求引數被篡改?

請求的唯一性(不可複製)

為了保證資料在通訊時的安全性,我們可以採用引數簽名的方式來進行相關驗證。

案列分析

後台介面:以下簡稱api

上**啦 -_-!

一、不進行驗證的方式

api查詢介面:

如上,這種方式簡單粗暴,通過呼叫getproducts方法即可獲取產品列表資訊了,但是 這樣的方式會存在很嚴重的安全性問題,沒有進行任何的驗證,大家都可以通過這個方法獲取到產品列表,導致產品資訊洩露。

那麼,如何驗證呼叫者身份呢?如何防止引數被篡改呢?

二、md5引數簽名的方式

我們對api查詢產品介面進行優化:

2.sign簽名,呼叫api 時需要對請求引數進行簽名驗證,簽名方式如下: 

a. 按照請求引數名稱將所有請求引數按照字母先後順序排序得到:keyvaluekeyvalue...keyvalue  字串如:將arong=1,mrong=2,crong=3 排序為:arong=1, crong=3,mrong=2  然後將引數名和引數值進行拼接得到引數字串:arong1crong3mrong2。 

b. 將secret加在引數字串的頭部後進行md5加密 ,加密後的字串需大寫。即得到簽名sign

新api介面**:

注:secret 僅作加密使用, 為了保證資料安全請不要在請求引數中使用。

如上,優化後的請求多了key和sign引數,這樣請求的時候就需要合法的key和正確簽名sign才可以獲取產品資料。這樣就解決了身份驗證和防止引數篡改問題,如果請求引數被人拿走,沒事,他們永遠也拿不到secret,因為secret是不傳遞的。再也無法偽造合法的請求。

但是...這樣就夠了嗎?細心的同學可能會發現,如果我獲取了你完整的鏈結,一直使用你的key和sign和一樣的引數不就可以正常獲取資料了...-_-!是的,僅僅是如上的優化是不夠的

請求的唯一性:

為了防止別人重複使用請求引數問題,我們需要保證請求的唯一性,就是對應請求只能使用一次,這樣就算別人拿走了請求的完整鏈結也是無效的。

唯一性的實現:在如上的請求引數中,我們加入時間戳 :timestamp(yyyymmddhhmmss),同樣,時間戳作為請求引數之一,也加入sign演算法中進行加密。

新的api介面:

如上,我們通過timestamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈結也是無效的。

sign簽名安全性分析:

通過上面的案例,我們可以看出,安全的關鍵在於參與簽名的secret,整個過程中secret是不參與通訊的,所以只要保證secret不洩露,請求就不會被偽造。

總結no excuse~

api介面簽名驗證 MD5

你在寫開放的api介面時是如何保證資料的安全性的?先來看看有哪些安全性問題在開放的api介面中,我們通過http post或者get方式請求伺服器的時候,會面臨著許多的安全性問題,例如 請求 身份 是否合法?請求引數被篡改?請求的唯一性 不可複製 為了保證資料在通訊時的安全性,我們可以採用引數簽名的...

API介面簽名驗證

系統從外部獲取資料時,通常採用api介面呼叫的方式來實現。請求方和介面提供方之間的通訊過程,有這幾個問題需要考慮 1 請求引數是否被篡改 2 請求 是否合法 3 請求是否具有唯一性。今天跟大家 一下主流的通訊安全解決方案。引數簽名方式 這種方式是主流。它要求呼叫方按照約定好的演算法生成簽名字串,作為...

API介面簽名驗證

api介面分為開放介面和私密介面。什麼是開放介面?什麼是私密介面?我們乙個乙個介紹它們簽名的驗證,先介紹開放api介面。下面我們稱呼發布介面方為 api arg1 value1,name fdfd,age 12 按照引數名的字母前後順序進行重新排序 3.然後再將排序好的引數,加上secrte 加上當...