一.接口安全的必要性

最近我們公司的小程序要上線了，但是小程序端是外包負責(zé)的，我們負責(zé)提供后端接口。這就可能會造成接口安全問題。一些別有用心的人可以通過抓包或者其他方式即可獲得到后臺接口信息，如果不做權(quán)限校驗，他們就可以隨意調(diào)用后臺接口，進行數(shù)據(jù)的篡改和服務(wù)器的攻擊，會對一個企業(yè)造成很嚴重的影響。

因此，為了防止惡意調(diào)用，后臺接口的防護和權(quán)限校驗非常重要。

雖然小程序有HTTPs和微信保駕護航，但是還是要加強安全意識，對后端接口進行安全防護和權(quán)限校驗。

二.小程序接口防護

小程序的登錄過程：

1. 小程序端通過wx.login()獲取到code后發(fā)送給后臺服務(wù)器
2. 后臺服務(wù)器使用小程序的appid、appsecret和code，調(diào)用微信接口服務(wù)換取session_key和openid（openid可以理解為是每個用戶在該小程序的唯一識別號）
3. 后臺服務(wù)器自定義生成一個3rd_session，用作openid和session_key的key值，后者作為value值，保存一份在后臺服務(wù)器或者redis或者mysql，同時向小程序端傳遞3rd_session
4. 小程序端收到3rd_session后將其保存到本地緩存，如wx.setStorageSync(KEY,DATA)
5. 后續(xù)小程序端發(fā)送請求至后臺服務(wù)器時均攜帶3rd_session，可將其放在header頭部或者body里
6. 后臺服務(wù)器以3rd_session為key，在保證3rd_session未過期的情況下讀取出value值（即openid和session_key的組合值），通過openid判斷是哪個用戶發(fā)送的請求，再和發(fā)送過來的body值做對比（如有），無誤后調(diào)用后臺邏輯處理
7. 返回業(yè)務(wù)數(shù)據(jù)至小程序端

會話密鑰session_key 是對用戶數(shù)據(jù)進行加密簽名的密鑰。為了應(yīng)用自身的數(shù)據(jù)安全，開發(fā)者服務(wù)器不應(yīng)該把會話密鑰下發(fā)到小程序，也不應(yīng)該對外提供這個密鑰。

session_key主要用于wx.getUserInfo接口數(shù)據(jù)的加解密，如下圖所示：

sessionId

在微信小程序開發(fā)中，由wx.request()發(fā)起的每次請求對于服務(wù)端來說都是不同的一次會話。啥意思呢？就是說區(qū)別于瀏覽器，小程序每一次請求都相當于用不同的瀏覽器發(fā)的。即不同的請求之間的sessionId不一樣（實際上小程序cookie沒有攜帶sessionId）。

如下圖所示：

實際上小程序的每次wx.request()請求中沒有包含cookie信息，即沒有sessionId信息。

但是我們可以在每次wx.request()中的header里增加。

接口防護方法

• 使用HTTPS防止抓包，使用https至少會給破解者在抓包的時候提高一些難度
• 接口參數(shù)的加密，通過md5加密數(shù)據(jù)+時間戳+隨機字符串（salt），然后將MD5加密的數(shù)據(jù)和時間戳、原數(shù)據(jù)均傳到后臺，后臺規(guī)定一個有效時長，如果在該時長內(nèi)，且解密后的數(shù)據(jù)與原數(shù)據(jù)一致，則認為是正常請求；也可以采用aes/des之類的加密算法，還可以加入客戶端的本地信息作為判斷依據(jù)
• 本地加密混淆，以上提到的加解密數(shù)據(jù)和算法，不要直接放在本地代碼，因為很容易被反編譯和破解，建議放到獨立模塊中去，并且函數(shù)名稱越混淆越難讀越安全。
• User-Agent 和 Referer 限制
• api防護的登錄驗證，包括設(shè)備驗證和用戶驗證，可以通過檢查session等方式來判斷用戶是否登錄
• api的訪問次數(shù)限制，限制其每分鐘的api調(diào)用次數(shù)，可以通過session或者ip來做限制
• 定期監(jiān)測，檢查日志，偵查異常的接口訪問

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論