微信小程序的修炼五脉（修仙）

声明

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测以及文章作者不为此承担任何责任。 雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

No.1

前言

仰之弥⾼，钻之弥坚，瞻之在前，忽焉在后。只有前⼏篇⽂章中所分享的技术是远远不够的，我们必须不断地思考以及学习来提⾼我们⾃身对渗透测试微信⼩程序的修为。在这第四篇⽂章中，敝⼈认为依然还是有许多实⽤知识可分享给⼤家的，笔者会从“开发者⼯具”、“⼩程序后端”、“第三⽅”三个⻆度展开描述，希望读者可学到⼀些有所升华。

No.2

强龙压得过开发者

由于微信⼩程序不可以选择发布范围哪些⼈可⻅哪些⼈不可⻅，默认是对全⽹公开的，也就是⼩程序⼀ 旦上线发布任何⼈有⼀定⼏率访问到此⼩程序。

（注：企业微信⼩程序可设置发布范围，但前提是：1. 对应企业使⽤企业微信作为办公通讯软件；2.开发守规矩的设置了发布范围。）

我们以“内部”⼆字为例在 微信⼩程序中搜索可以看到⼤量的公司内部办公⼩程序：

那么当开发⼜想贪图微信⼩程序的便利，奈何公司⽤的不是企业微信⽆法设置为内部⼩程序，但⼜想不让吃⽠群众以及此时在看这篇⽂章的读者们“不⼩⼼”访问到他们的内部⼩程序时，他们也许会使⽤下⾯的这类常⻅⼿法：普通⼈在⼿机端打开这个微信⼩程序时，会⾃动以 webview 的⽅式前往他们的官⽹，除此以外别⽆其他功能。

有些⼈看到这个⻚⾯时可能直接退出了，⼼⾥空落落的，但实际上⼩程序后别有洞天，我们将⼩程序解包之后放到开发者⼯具中⼀跑，我们可以看到下图才是这个⼩程序真实的内容：

原来⼩程序在⼊⼝处有⼀个校验，会判断当前⼩程序是否处于开发环境或者企业办公⽹环境，若存在显示真实的⼩程序内容，若不存在重定向⾄公司官⽹⻚⾯。其JS实现代码如下：

当新⼿在导⼊⼀个解包之后的⼩程序时，在填⼊“AppID”处肯定⾮常想填写对应⼩程序的真实（原本） ID，但是微信开发者⼯具有“AppID”验证机制，每个⼈只能使⽤⾃⼰名下绑定的“AppID”：

那么当我们使⽤⾃⼰的“AppID”导⼊⼩程序时，这个⼩程序已经不再是原来的那个⼩程序，由于“AppID”的变化，当微信⼩程序调⽤“wx.login”时⽣成的“js_code”并不能与服务器后端的所绑定真实的“AppID”所进⾏的调⽤微信API的操作相兼容（即⽆法执⾏ jscode2session 操作）。因此⼩程序在登录等⼀系列列需要“openid”，“js_code”，“Session_key”等参数的操作均可能会失败，您会看到各种各样的错误提示，开发者⼯具红满天：

此时我们有两种解决⽅案，其⼀我们可以在⼿机上正常的⼩程序中开启抓包模式，抓取⼀个由正确“AppID”⽣成的code值，然后拿着⼩本本记在⼀遍（注意此时不要放包，直接drop掉，因为code是⼀次性有效的）。接着我们来到开发者⼯具中，观察他的登录代码如下：

g.code 处便是在开发者⼯具内⼩程序获取到的不合法的code值，他会将其通过 /thor/iv/login 传递 给后端使⽤。我们可以直接暴⼒修改本地代码，将⼩程序通过系统功能获取 code 并将其作为变量传递 给后端API的操作修改为API直接请求我们刚刚得到的 code ，将其写死⽽不是通过变量引⼊，可谓 code 在变我不变：

第⼆种⽅式相交之下⽐较“温柔”些，例如在如下示例⼩程序中，⼩程序会先尝试去 Storage 中读取 userInfo 数据判断⽤户是否已经登录，若⽤户已经登陆并且数据没有过期则不执⾏登录相关操作，直 接使⽤现成本地保存的数据：

此时我们只需分析 userInfo 的数据结构，并构造相应的内容写⼊ Storage 中即可⼀劳永逸不需要再去执⾏登录操作：

当然也可以在每个登录的⼝⼦处将登录数据写死，虽然不推荐这种⽅法，但：

再解决完登录问题之后，便可正式开始对程序进⾏⼀系列测试了。这⾥还有⼀个⼩技巧，在有些⼩程序 中开发者会留下⼀个可全局切换后端从⽣产环境到测试环境的接⼝，有些时候⽣产环境虽然没有漏洞， 但在测试环境中却能测出来，虽然会被降级处理，但⾄少也是⼀个漏洞。如下示例⼩程序中同时存在“⽣ 产环境”和“测试环境”两份配置代码：

我们将程序中调⽤“⽣产环境”配置的代码修改为调⽤“测试环境”配置的内容即可快速将⼩程序切换⾄测试 环境：

在实际测试中，有些⼩程序功能并不是开放给全部⽤户所使⽤的，例如某⼀个商品⽀付成功之后的后续操作，⼤多数情况下我们并不会去实际购买商品，这时候如果我们⼀个个构造数据包进⾏测试会显的⽐ 较麻烦，此时我们就可以利⽤开发者⼯具强⾏修改⼩程序逻辑，直接通过⼩程序本身去构造数据包会较 为便捷，⽐如在某次测试中我们直接在⼩程序⾸⻚使⽤“wx.navigateTo”强⾏跳转⾄订单⽀付成功⻚⾯， 并传⼊⼀个假的订单参数：

接着⼩程序会带着我们写⼊的订单号直接来到⽀付成功界⾯，我们可以看到下图⽀付成功界⾯中还有其他功能，利⽤此种⽅法可以快速的对⼩程序进⾏测试，并让⼩程序⾃⼰去构造数据包，再也⽆需⾃⼰⼀个个⼿动的去构造API。

并且在⼀些IOS/安卓程序中对数据包进⾏了数据内容加密或者验签操作，有时候可能⼀时间⽆法找到解密⽅法。此时我们可以考虑其是否有对应的H5⻚⾯或⼩程序，可能这些系统中并没有强制对数据内容进 ⾏加密/签名或使⽤了相同（相类似）的加密/签名⽅法。⽽由于微信⼩程序的特性我们可在源码中轻易 找到对应的解密⽅式以及“key”：

并且我们可以在⼩程序中直接在其进⾏加密/签名前修改暴⼒修改对应变量的内容，让⼩程序去主动加 密/签名修改之后的数据，这样就不需要我们去⼀个个⼿动构造加密/签名之后的数据内容了，也⽆需考虑时间戳带来的有效性问题，掌握了它你就是下⼀任时间管理⼤师。

No.3

第三方？可靠吗

古有傻⽠速成现有⼀键⽣成，⾕歌⼀下我们能看到各类形形⾊⾊层次不⻬的⼩程序在线⽣成程序，他们 为您提供从前端到后端，从推⼴到托管的⼀条⻰服务，并且服务费⾮常便宜（甚⾄都⽆需花钱），您可以更具⾃⼰的喜好快速创建各类⼩程序，甚⾄是⼀个带有⽀付功能的完整购物⼩程序。

例如某⼩程序⼀键⽣成平台“应⽤⼤厅”中展示结果如下，模板⼗分丰富并且整⼀个业务⾮常成熟，可以说每⼀个⼩程序⽣成平台都积累了⼤量的⾮商业已经商业⽤户，也有很多⼤⼚会将⾃⼰的业务交给这些 供应商去做。但这也引发了⼀个问题，虽然这些平台⽣成的⼩程序五花⼋⻔，但后端还是同⼀套，只要有⼀个API存在漏洞，那么在此平台上⽣成的⼏乎所有⼩程序都遭殃，正式千⾥之堤溃于蚁⽳。然⽽这些平台⻥⻰混杂，没有⼀个有效的监管机制，并且很多⼚商本身并不是特别注重安全问题，此外即使有“⽩ 帽⼦”发现了这些漏洞也很难或者有⼀定的⻛险将漏洞反应给⼚商。

例如笔者在测试某SRC的⼩程序时发现旗下有⼀款利⽤某⼩程序⼀键⽣成平台⽣成的商店APP，⽤于出售其公司零售商品。笔者在授权测试中发现⼩程序在调⽤名为 login 的后端API时会明⽂返回当前的 session_key

⽽这套⼩程序的系统正是通过微信⼿机号快捷登录功能绑定商城账户⾄对应微信的，我们便可以通过之前讲过的⽅法修改加密数据包，从⽽实现任意⽤户登录，例如笔者在测试中成功使⽤“13588888888”⼿ 机号登录⾄购物商城：

还敢放⼼的⽤⼀键⽣成的⼩程序吗，想让他们重视你的⽤户数据你疯啦，可能当他们意识到⾃⼰的系统被骇时会优先推脱责任⽽不是反思⾃⼰。前⾯说的是第三⽅⼀键⽣成⼩程序平台，此外会有许多⼈偏 向⾃⼰搭建现成⼜⽐较可控的“第三⽅⼩程序管理平台”，例如我们使⽤“Sumap 全球⽹络空间超级雷达”系统以“⼩程序后台”为关键字，便搜索到了许多⼩程序后台，这些结果中⼤部分都是直接使⽤第三⽅系统搭建的，其中⽐较出名的有“微擎”、“微赞”这些第三⽅管理平台。

这些⽼牌管理平台本身较为安全可控，爆出的漏洞也⽐较少，⽽且也可以⾃助扩展许多模板及插件，深受企业⻘睐。但插件漏洞终究是⼀个跨不过去的坎，随时有可能成为⼀颗定时炸弹，甚者⼀些管理员压 根就不知道⾃⼰装了有漏洞的插件。例如在某次授权测试中我们发现某商城⼩程序后端使⽤了“微擎”管理平台最新版本并⽆已知安全漏洞，接着我们通过查看其对应的⼩程序源码发现其⻚⾯⽂件夹名称均以 sudu8_page 开头，可以判断出使⽤了“万能⻔店⼩程序模块”插件。在这个插件的某个⽼版本中存在⼀ 处SQL注⼊漏洞，我们可利⽤此漏洞轻松拿下此⼩程序。

除此之外微信⼩程序本身也是⽀持插件功能的，我们可以在⼩程序详情⻚⾯的“服务⽀持”中查看到当前⼩程序使⽤的全部插件名称和他对应的服务商，⼀旦这些插件出现了漏洞也会对⼩程序本身的安全造成⼀定的影响，虽然由于微信⼩程序的安全机制，在⼤多数情况下插件的安全问题并不能直接对⼩程序后 端造成破坏。例如下图为某⼩程序所引⽤的插件，若其中⼀个插件存在漏洞，攻击者还是可以利⽤他们来进⾏包括但不限于修改⼩程序显示内容、窃取⽤户信息等恶意操作。

⼩程序插件直接在微信客户端内是⽆法搜索得到的，但我们可以通过登录⾃⼰的⼩程序微信开放平台账 户在“设置” --> “第三⽅设置” --> “添加插件”中搜寻⼩程序插件。在这些插件中也不乏许多内部组件：

接着我们可以点击“查看详情”，如果我们⽐较幸运可以看到开发者的私⼈电话号码以及他的邮箱：

微信为我们提供了⼀个更加好玩的功能，我们继续点击“开发⽂档”便可⽴刻获取此⼩程序的使⽤说明书，⽣产⼒神器有⽊有：

当然微信⼩程序插件并不能直接⽤在我们⾃⼰的⼩程序上，点击添加之后还有⼀个申请过程需要开发者进⾏⼀个确认才可，但是如果你申请接⼊的⼩程序伪装的⾜够像那么开发者将你审核通过的⼏率是⾮常 ⼤的。⼀旦我们拿到了这些插件的介⼊权限就相当于给你了⼀个开通了⼀个VPN账户，或者更恰当点说 是在单点登录的回调地址中给你留了⼀个⽩名单。

除了⼩程序本身可以使⽤第三⽅插件之外，微信还提供了⼩程序账户第三⽅授权功能功能。您可以通过 此功能将对于的⼩程序账户授权给第三⽅平台使⽤，⼀旦授权第三⽅平台等于接管了您的账户可以执⾏ 任何操作（视实际给予权限⽽定）。虽然开发者在登录微信开放平台时基本上是⾮常安全的，即使获取 到了账户及密码也需要本⼈微信扫码确认才能登录，但是权限⼀旦授权给第三⽅，第三⽅的安全措施可 能就没有这么的完善，这便让我们在测试中有机可乘。

那么如何查看微信⼩程序授权给了那些第三⽅平台呢？贴⼼的微信也为我们准备好了，我们可以在⼩程 序详情⻚⾯的“该账号的部分功能由以下服务商提供”中查看到当前⼩程序账户被授权平台对应的公司名 称。例如下图我们可以看到“Hack Inn”⼩程序的账户权限授权给了名为“宁波邻家⽹络科技有限公司”的服务商：

通过搜索公司名称，我们可以很快的找到其对应被授权的平台是“草料⼆维码”。那么如果这个平台存在某个越权漏洞（当然没有！就是打个⽐⽅），我们便可以轻松接管被授权在此平台上的所有微信⼩程序，此时我的⼩程序还是我的，你的⼩程序也是我的。

No.4

web还是那个web

⼩程序渗透来渗透去，归根结底还是在做各种WEB的测试，只不过图形界⾯从浏览器上移⾄微信中罢 了。Web安全没做好，⼩程序再华丽也只是个花瓶，虽然讲的再多笔者也想单独把这个作为⼀个⼩节来 单独谈⼀谈。⼩程序的web后端其实有三种情况：和H5、⼿机APP、⽹⻚使⽤同⼀套API系统，和⼿机 APP使⽤同⼀套API系统，单独开发⼀套API系统（使⽤第三⽅系统包含在内）。那么当微信⼩程序的API 为单独开发时，并且同时存在相应的H5、⼿机APP和⽹⻚版，我们可以对后端系统的安全性做如下排 序：⽹⻚版＞⼿机APP＞H5 ≥ ⼩程序，微信⼩程序在这套产品中往往是最为脆弱的。柿⼦还得挑软的 捏，在许多渗透测试中，⽹⻚不⾏、APP不⾏，往往微信⼩程序总能作为突破⼝，成为捷径中的快速 路。很多情况下，开发者本身对微信⼩程序并不是那么重视，APP和⽹⻚为其客户的主要⼊⼝，上头说 要搞⼀个，于是乎随随便便的搞了⼀个，本身整个项⽬并不重视，那么对其开发产品的安全性也相较于 APP和⽹⻚产品没那么重视。

微信⼩程序后端主要存在的漏洞⼤类有：

1、各类逻辑漏洞

2、⽔平越权

3、SQL注⼊

4、任意⽂件 上传等

这些漏洞中不包含XXS漏洞，因为微信⼩程序的特性是不能执⾏动态脚本的，所以此类漏洞不 可能会在⼩程序中存在。但此时并不代表⽆法挖掘XSS漏洞，这⾥有⼀个常⽤的思路分享给⼤家：例如 在如下示例⼩程序中⽤户在⼩程序内登陆之后可以使⽤评论功能留⾔，接着我们看到有“分享⾄朋友 圈”功能。微信⽬前是不⽀持在朋友圈内直接分享⼩程序⻚⾯的，所以开发者开发了⼀个可以浏览⽂章以 及评论内容的⽹⻚供使⽤者分享⾄朋友圈使⽤。此时我们可以在⼩程序内使⽤恶意内容留⾔，然后将此 ⽂章分享⾄朋友圈来获取对应的Web⻚⾯，若开发者在Web⻚⾯内并未做严格的过滤，那么将会成功触发XSS。

除XSS之外其他需要⽤户交互才能产⽣的漏洞例如：CSRF、JSON劫持、CORS劫持等需要⽤户交互才能 触发的漏洞基本上不会存在，因为这类攻击都是基于浏览器对⽤户的信任，⽽⼩程序内⽤户的⼀切操作 都是在微信沙盒内完成的，攻击者⽆法通过浏览器利⽤⽤户在⼩程序内的身份凭据来完成攻击。此外类 似于URL跳转、CRLF注⼊、⽬录遍历等的中/低危漏洞由于后端API的特性（⼤多以JSON格式返回数据） ⽽基本上也不复存在。我们在渗透测试是不应该⾸先考虑这些基本上不会存在的漏洞，从前⽂提到的四 ⼤类漏洞作为切⼊点才是上策，浪费时间的事⼉咋们没必要做，况且这些漏洞本身的危害也并没有这 么“直接”哪怕存在也最多算个中危。此外不得不提到⼀个虽然没有任何技术含量确是渗透界第⼀⼤杀⼿的“弱⼝令”⼤师，弱⼤师善于利⽤⼈ ⼼，⼀出⼿打遍天下⽆敌⼿，再强的WAF也是浮云。⼩程序⾃然离不开⼀个web管理端，它可能位于：同服务器⽗⽬录下 https://example.com/ 、同服务器异⽬录下 https://example.com/manage/ 、同 服务器不同端⼝下 https://example.com:65535/ 、不同服务器下 https://admin.example.com/ (往往在⼀个C段)，若测不出其他漏洞，找⼀个管理端弱⼝令回家也是极好。

No.5

无限遐想

除了上述提到的各种针对⼩程序的渗透⽅法，是否还能扩展出更加丰富多彩的攻击⼿段呢？⽐如N年前 最有名的 XcodeGhost 事件，对苹果Xcode开发者⼯具进⾏修改加⼊恶意代码并分发⾄第三⽅下载渠 道；前段时间爆出的 PHPStudy后⻔ 事件，同样的⼿法同样的第三⽅下载渠道分发。这样⼀次次看似漏 洞百出的供应链攻击到最后终了时效果却⾮常的好，⽤最直的钩钓最刚的⻥。未来在红蓝对抗中是否也 会出现针对微信⼩程序的供应链攻击？将“微信⼩程序开发者⼯具”以及市⾯上各类嵌⼊微信⼩程序的“第 三⽅SDK”修改并植⼊恶意代码后通过各种下载渠道分发，虽然说攻击精准度不⾼但只要⽹撒的⼴⻥⼉应 有尽有。此外微信⼩程序本身是否存在⼀些安全漏洞呢，是否可以突破⼀些⼩程序机制呢，还有太多太多需要我们去研究，值得我们去研究......