微信小程序中關于安全的示例分析

這篇文章主要介紹微信小程序中關于安全的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

一.小程序框架概述

小程序抽象框架

視圖層

包含WXML、WXSS和頁面視圖組件。

WXML是一種類似XML格式的語言，支持數據綁定、條件渲染、列表渲染、自定義模板、事件回調和外部引用

WXSS是一種類似CSS格式的語言，用于描述WXML的組件樣式，決定WXML中的組件如何顯示

組件是框架提供的一系列基礎模塊，是視圖層的基本組成單元，包含表單組件、導航、地圖、媒體組件等常用元素，如圖1說明當前小程序支持的的視圖組件。

圖1-小程序視圖組件

邏輯層：

包含小程序注冊、頁面注冊和功能API。程序注冊代碼位于app.js，頁面框架注冊位于app.json，如圖2為官方示例小程序的app.js和app.json。功能API當前包含網絡請求功能、文件處理功能、數據存儲功能、微信的開放接口功能等，詳見微信官方說明，如圖3所示。

圖2-小程序注冊代碼示例

圖3-小程序功能API示例

原生實現層

承載小程序依賴的具體操作，由微信APP支撐實現，包括tbs內核、JSAPI框架、初始化小程序配置、功能接口實現等，實現代碼主要位于com.tencent.mm.plugin.appbrand包，關聯功能有微信平臺原有的數據存儲能力、二維碼能力、網絡請求能力、支付能力等。

小程序調用框架

調用框架簡圖

上圖主要說明小程序功能邏輯框架流程，由頂層的小程序實現代碼（類似js），到微信底層支撐實現模塊的調用流程，通過微信JSAPI框架支撐頁面到本地實現的橋接調用。小程序緩存數據存放在Storage中，對應文件為DB數據庫；小程序文件操作通過Hash機制進行映射，并存儲在外部存儲空間。

承載小程序展示的組件是.plugin.appbrand.ui.AppBrandUI、.plugin.appbrand.ui.AppBrandUI1、.plugin.appbrand.ui.AppBrandUI2、.plugin.appbrand.ui.AppBrandUI3、.plugin.appbrand.ui.AppBrandUI4，五個組件實現邏輯相同，AppBrandUI1- AppBrandUI4繼承自AppBrandUI，圖5為每個承載小程序的Android組件定義。

圖5-承載每個小程序展示的組件定義

支持最多同時有五個小程序在加載運行狀態，每個小程序使用獨立進程運行，如果當前開啟的小程序已位于緩存進程中，則無需重新加載直接開啟（速度快），否則重新加載并替換（如果已有五個緩存進程存在）存在時間最久的緩存進程，若當前未滿五個緩存進程，則從未用進程中隨機取得一個使用。下圖展示微信APP同時已開啟過五個小程序的對應進程。

圖6-小程序的進程緩存示意圖

小程序初始化流程

小程序初始化流程包括開發者后臺控制關鍵配置和安全的配置更新流程。

后臺控制關鍵配置

小程序后臺控制的配置信息主要包括小程序名稱、圖標、最大webview深度、最大請求數、請求合法域名列表、下載合法域名列表和上傳合法域名列表、socket合法域名列表以及APP包的基本信息等，動態加載的配置信息相關代碼詳見【附錄1】

安全的配置更新流程

啟動小程序檢查是否需從服務端更新最新配置，如果需更新則下載最新配置到本地APP，如圖7說明當前設備上已有使用的9個小程序的初始化數據，以二進制文件形式（后綴為.wxapkg）存放在APP目錄下。在初始化階段完成小程序的關鍵屬性更新和配置，此部分屬性配置完全由后端配置控制，在更新傳輸和本地存儲被惡意篡改的可能性極低，提取配置信息的實現代碼詳見【附錄2】。

圖7-小程序的初始化數據文件示意圖綜上內容，大白為澤友們介紹了小程序的框架部分，接下來，大白要介紹的就是小程序核心
功能模塊安全分析，繼續圍觀哦！

二.小程序功能模塊安全

功能模塊安全大白將分為6小部分分析介紹，分別是：

1、網絡傳輸安全
2、數據存儲安全
3、文件存儲安全
4、掃碼二維碼安全
5、微信開放接口安全
6、小程序釣魚風險
7、泄露數據到微信隱患

下面我們先看一下小程序的網絡傳輸安全。

網絡傳輸安全

支持發起通用請求、文件上傳下載、WebSocket通訊機制。

Https校驗安全

通用request網絡請求僅支持采用https，處理請求的接口位于com.tencent.mm.plugin.appbrand.g.c中，包含url校驗、域名校驗、發起請求和處理響應結果。圖8圖9分別為官方正式DEMO和某銀行APP請求包示意圖。

圖8官方DEMO request功能請求包

圖9-某銀行APP request功能請求包

Https校驗采用類似瀏覽器的策略，通過系統原生的URL.openConnection()方式請求，證書校驗的策略為校驗公鑰證書的根證書是否在合法CA列表憑證中。因此自簽名證書無法使用；針對特定終端設備，即是校驗公鑰證書的根證書是否在受信任的憑據中，在設備被惡意安裝代理根證書的前提下，存在被中間人攻擊的風險。Request網絡請求實現代碼詳見【附錄3】。

通過域名控制可訪問的url

由后臺配置小程序支持的域名，僅可訪問已配置域名的url，校驗過程會將配置的域名先下載到本地，然后每次請求時本地做域名檢查通過后才發起。域名檢查代碼實現詳見【附錄4】，圖10展示了域名不匹配進行錯誤請求的示例。

圖10-小程序域名控制檢查

此外，對于通用request請求平臺會進行請求超時控制（當前應該是5s），當請求超過5s即會被中斷（文件上傳操作也有超時中斷控制），超時后請求將被拋掉。

網絡下載安全

同樣僅支持從含有已配置域名的url下載資源，不是走http/https協議。下載成功后臨時存放，通過自定義協議wxfile進行訪問，映射到SD卡上目錄 /sdcard/tencent/MicroMsg/wxafiles/wx_id/tmp_[hash_value]。

圖11-網絡下載文件示意圖

文件上傳安全

上傳至小程序合法域名下的服務器上，并保存臨時文件在SD卡的文件存儲區域/sdcard/tencent/MicroMsg/wxafiles/wx_id/tmp_[hash_value]。

圖12-文件上傳示意圖

小程序外鏈url規范

小程序在微信的生態下運行，不開放給個人使用（需要企業）。在小程序中不允許調整到外部網站，也不允許放鏈接。同時微信在小程序發布前會對小程序進行審核。

圖13-小程序不允許外鏈url說明

數據存儲安全

以（key，value）形式存放在本地緩存，將小程序需要存儲的key/value數據直接存儲到Storage DB緩存，小程序進行數據保護需要自行做加密處理。數據存儲在本地DB，微信APP會對DB數據整體做本地加密保護，所以小程序本地存儲數據的安全性依賴于微信數據庫加密方案的安全，策略與EnMicroMsg.db類似，如下圖所示。

圖14-本地數據存儲示意

文件存儲安全

文件保存在SD卡/sdcard/tencent/MicroMsg/wxafiles/wx_id/目錄下，通過wxfile://協議指向SD卡目錄下的文件。

存放SD卡的文件有做完整性校驗，無法被篡改。首先，最終存儲的文件名是：對稱加密（文件流內容Alder32校驗和|原始文件名）生成的，最終文件名和文件內容會通過自校驗判斷完整性；其次，本地緩存是通過HASH映射查找文件。所以即使能破解文件名和文件內容，繞過文件自身簽名校驗，篡改為攻擊者的偽造文件，小程序APP也無法映射到該偽造文件進行使用。

掃碼二維碼安全

掃碼功能（wx.scanCode）依賴微信APP的原生的掃碼功能；生成小程序特定頁面的直達二維碼，依賴于ACCESS_TOKEN，而ACCESS_TOKEN是通過小程序（公眾號）私有的APPID和appsecret請求得到，攻擊者無法獲知到該信息偽造生成二維碼。

微信開放接口安全

用戶信息獲取，包含以下信息：

接口返回的明文數據會進行簽名校驗，需要依賴登錄session_key；接口返回的敏感數據會通過密文返回，解密算法依賴登錄session_key。攻擊者無法獲知用戶的session_key進行破解，竊取用戶數據。

此外分享、客服消息、模板消息中輸入的內容僅會以文本形式輸出；模板消息會將數據通過https傳輸到服務器，而后推送到客戶微信服務通知；微信支付功能繼承微信平臺原有的功能，安全性較為可靠。

開放平臺大部分功能會先通過wx.login獲得code；然后使用該code換取openid；以此openid進行既定的微信功能操作，比如發送模板消息推送、發起微信支付等。

圖15-開放平臺發布模板請求示意圖

小程序釣魚風險

微信小程序以唯一appid標識身份，不同小程序擁有不同的appid。如果惡意開發者偽造流行的小程序APP，如美團、大眾點評，制作一個仿冒的微信小程序，且使用不同的appid，有可能繞過微信的審核流程發布到市場。小白用戶如無辨識能力，極可能被釣魚受騙。但由于小程序無法嵌入url跳轉，同時有訪問域名的控制，使得釣魚風險在一定程度上減輕。小程序釣魚風險依賴于微信平臺的發布審核、監管控制。

泄露數據到微信隱患

微信小程序的網絡請求通過微信APP實現轉發，微信平臺可能可以獲取到小程序的所有網絡請求和存儲數據，因此對于小程序業務敏感的數據，建議由小程序再做一層保護；小程序的操作軌跡日志會加密傳送到騰訊TBS后臺，如下圖所示。

圖16-操作軌跡日志監控上傳

三.小程序賬戶使用安全

通過目前使用體驗，發現當前存在三種賬戶形式：

方式一：

通過wx.getUserInfo獲取的微信用戶信息，以openid標識一個用戶應用到小程序；

方式二：

通過公眾平臺appid+appsecret+code，換取session_key/openid，并生成小程序第三方session，在小程序的服務器維護第三方session和微信session_key/openid的關聯；客戶端使用第三方session進行請求；

方式三：

通過小程序內部自實現的登錄模塊，如手機號+動態驗證碼登錄

方式一是一種弱賬戶體系設計，小程序本身無法獲得微信用戶的標識信息，如手機號、身份證或銀行卡，依賴于微信開放平臺接口可以提供的用戶信息，詳見2.5節，一般會在頁面上展示微信用戶昵稱和頭像，如下圖17所示。

圖17-使用微信信息登錄

方式二和方式三是強賬戶體系，方式二類似微信公眾號的授權機制，通過小程序獲得的code和微信用戶基本信息，到第三方服務器獲取訪問的token（第三方session），第三方服務器維護用戶使用的session與微信session_key/openid的關聯關系。圖18為微信官方提供的登錄實現時序圖，圖19為某小程序授權登錄的請求過程。

圖18-官方提供的授權登錄實現方案

圖19-某小程序授權登錄過程

以上第一個請求通過code和微信基本用戶信息到第三方服務器換取token，而后的請求通過token請求用戶個人數據，如團購代金券使用歷史記錄。方式二不能將微信公眾平臺的appsecret或者session_key（屬于敏感信息）傳遞到客戶端，否則可能導致安全攻擊。方式三屬于小程序自身實現方式，依賴自身實現的安全性，與微信平臺無關。

四.總結

說了這么多，大白也該總結一下了，大致如下8點：

1、框架上繼承了微信成熟的JSAPI框架和底層的TBS瀏覽器內核；

2、小程序的關鍵信息完全由后臺控制進行配置，如可訪問的域名信息；

3、通用網絡傳輸使用Https，并對訪問域名進行校驗控制，無法抵御攻擊者在本地安裝代理證書實施中間人攻擊的威脅；

4、本地數據存儲采用（KEY，VALUE）形式存放在DB，數據的保護繼承了微信的數據庫加密防護策略；

5、本地文件存儲采用HASH映射機制進行文件定位，文件存儲在外部存儲，本身通過自定義算法實現完整性校驗；

6、存在仿冒釣魚小程序的可能，依靠于微信平臺的審核監管能力；

7、針對特定小程序，由于是在微信平臺生態中運行，小程序自身仍需對敏感數據進行安全防護；

8、小程序登錄體系可以依賴微信接口和公眾號平臺，也可以由小程序自行實現。前者需要根據微信平臺的安全規范實施，后者則由小程序自行控制安全性。

五.附錄

下面大白補充一下上述文中4個附錄內容：

附錄1：小程序初始化后臺配置信息
a target="_blank" href="https://cache.yisu.com/upload/information/20200622/114/77967.jpg">附錄2：更新并提取后臺配置信息邏輯

附錄3：request網絡請求實現

附錄4：網絡請求域名校驗

以上是“微信小程序中關于安全的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！