小程序?qū)W習(xí)筆記-API接口安全
一.接口安全的必要性
最近我們公司的小程序要上線了桐款，但是小程序端是外包負(fù)責(zé)的，我們負(fù)責(zé)提供后端接口魔眨。這就可能會造成接口安全問題。一些別有用心的人可以通過抓包或者其他方式即可獲得到后臺接口信息侄刽，如果不做權(quán)限校驗朋凉，他們就可以隨意調(diào)用后臺接口，進行數(shù)據(jù)的篡改和服務(wù)器的攻擊杂彭，會對一個企業(yè)造成很嚴(yán)重的影響。因此所计，為了防止惡意調(diào)用赁炎，后臺接口的防護和權(quán)限校驗非常重要钾腺。
雖然小程序有HTTPs和微信保駕護航，但是還是要加強安全意識放棒，對后端接口進行安全防護和權(quán)限校驗。
二.小程序接口防護
小程序的登錄過程：
小程序端通過wx.login()獲取到code后發(fā)送給后臺服務(wù)器
后臺服務(wù)器使用小程序的appid吴旋、appsecret和code厢破，調(diào)用微信接口服務(wù)換取session_key和openid（openid可以理解為是每個用戶在該小程序的唯一識別號）
后臺服務(wù)器自定義生成一個3rd_session，用作openid和session_key的key值摩泪，后者作為value值，保存一份在后臺服務(wù)器或者redis或者mysql嚷掠，同時向小程序端傳遞3rd_session
小程序端收到3rd_session后將其保存到本地緩存，如wx.setStorageSync(KEY,DATA)
后續(xù)小程序端發(fā)送請求至后臺服務(wù)器時均攜帶3rd_session不皆，可將其放在header頭部或者body里
后臺服務(wù)器以3rd_session為key，在保證3rd_session未過期的情況下讀取出value值（即openid和session_key的組合值）能犯，通過openid判斷是哪個用戶發(fā)送的請求犬耻，再和發(fā)送過來的body值做對比（如有），無誤后調(diào)用后臺邏輯處理
返回業(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ū)別于瀏覽器叫惊，小程序每一次請求都相當(dāng)于用不同的瀏覽器發(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ù)一致泽铛，則認(rèn)為是正常請求辑鲤；也可以采用aes/des之類的加密算法，還可以加入客戶端的本地信息作為判斷依據(jù)
- 本地加密混淆月褥，以上提到的加解密數(shù)據(jù)和算法，不要直接放在本地代碼舀透，因為很容易被反編譯和破解决左，建議放到獨立模塊中去愕够，并且函數(shù)名稱越混淆越難讀越安全佛猛。
- User-Agent 和 Referer 限制
- api防護的登錄驗證，包括設(shè)備驗證和用戶驗證强衡，可以通過檢查session等方式來判斷用戶是否登錄
- api的訪問次數(shù)限制码荔，限制其每分鐘的api調(diào)用次數(shù)感挥，可以通過session或者ip來做限制
- 定期監(jiān)測，檢查日志触幼，偵查異常的接口訪問
