API接口手工防御被惡意調用和接口被攻擊
通常情況下的api接口防護有如下幾種：
- 使用HTTPS防止抓包，使用https至少會給破解者在抓包的時候提高一些難度
- 接口參數的加解密，通過md5加密數據+時間戳+隨機字符串(salt)，然后將MD5加密的數據和時間戳、原數據均傳到后臺，后臺規定一個有效時長，如果在該時長內，且解密后的數據與原數據一致，則認為是正常請求;也可以采用aes/des之類的加密算法，還可以加入客戶端的本地信息作為判斷依據
- 本地加密混淆，以上提到的加解密數據和算法，不要直接放在本地代碼，因為很容易被反編譯和破解，建議放到獨立模塊中去，并且函數名稱越混淆越難讀越安全。
- User-Agent 和 Referer 限制
- api防護的登錄驗證，包括設備驗證和用戶驗證，可以通過檢查session等方式來判斷用戶是否登錄
- api的訪問次數限制，限制其每分鐘的api調用次數，可以通過session或者ip來做限制
- 定期監測，檢查日志，偵查異常的接口訪問
在開發web端程序時，如果你的服務是放在外網的，你是無法完全阻止別人模擬客戶端來調用你的web api的。因為你的所有前端代碼用戶都能直接或間接的看到。
而在開發小程序項目時，前端的小程序代碼是上傳到微信服務器的，其他人想要直接看到或拿到源代碼的難度較大，因此小程序端相對安全些。
為什么要做接口防護和權限校驗?
有時候，黑客通過抓包或者其他方式即可獲得到后臺接口信息，如果不做權限校驗，黑客就可以隨意調用后臺接口，進行數據的篡改和服務器的攻擊。因此，為了防止惡意調用，后臺接口的防護和權限校驗非常重要。
小程序如何進行接口防護?
要進行小程序的接口防護，首先需要了解小程序的登錄過程，如下圖所示：
整個的流程如下：
- 小程序端通過wx.login()獲取到code后發送給后臺服務器
- 后臺服務器使用小程序的appid、appsecret和code，調用微信接口服務換取session_key和openid(openid可以理解為是每個用戶在該小程序的唯一識別號)
- 后臺服務器自定義生成一個3rd_session，用作openid和session_key的key值，后者作為value值，保存一份在后臺服務器或者redis或者mysql，同時向小程序端傳遞3rd_session
- 小程序端收到3rd_session后將其保存到本地緩存，如wx.setStorageSync(KEY,DATA)
- 后續小程序端發送請求至后臺服務器時均攜帶3rd_session，可將其放在header頭部或者body里
- 后臺服務器以3rd_session為key，在保證3rd_session未過期的情況下讀取出value值(即openid和session_key的組合值)，通過openid判斷是哪個用戶發送的請求，再和發送過來的body值做對比(如有)，無誤后調用后臺邏輯處理
- 返回業務數據至小程序端
ps：會話密鑰session_key 是對用戶數據進行加密簽名的密鑰。為了應用自身的數據安全，開發者服務器不應該把會話密鑰下發到小程序，也不應該對外提供這個密鑰。
session_key主要用于wx.getUserInfo接口數據的加解密，如下圖所示：
什么是sessionId?
在微信小程序開發中，由wx.request()發起的每次請求對于服務端來說都是不同的一次會話。啥意思呢?就是說區別于瀏覽器，小程序每一次請求都相當于用不同的瀏覽器發的。即不同的請求之間的sessionId不一樣(實際上小程序cookie沒有攜帶sessionId)。
如下圖所示：
實際上小程序的每次wx.request()請求中沒有包含cookie信息，即沒有sessionId信息。
那么我們能否實現類似瀏覽器訪問，可以將session保存到后臺服務器呢?
答案是肯定的。我們可以在每次wx.request()中的header里增加
- ## java的寫法，Jsessionid只是tomcat的對sessionId的叫法，其實就是sessionId
- header:{'Cookie': 'JSESSIONID=' + sessionId}
- ## thinkjs3.0 的寫法
- header:{'Cookie': 'thinkjs=' + sessionId}
效果如下圖所示：
在thinkjs3.0的后臺代碼中，sessionId被保存到了cookie里，可以通過：
- const session_id = this.cookie('thinkjs')
提取到sessionId的值
具體ThinkJS的實現代碼
首先創建sever端的代碼，如下圖所示：
cd到根目錄，運行：
- thinkjs new server
創建后臺代碼：
