记录一次微信小程序webview下h5页面被攻击及后续排查经过

前言

最近公司在微信小程序上架了一款应用，考虑到后续更新方便，其中大部分页面使用了webview组件内嵌h5这种模式来实现，很长一段时间功能都好好的，直到有一次突然有人反馈里面的某个操作跳转到了一个危险网站，由于小程序内部有安全保护机制，提示当前的页面已被拦截无法打开。

排查思路

恰巧的是这个操作对应的是一个大模型的接口调用，我刚刚开始怀疑是不是大模型采集数据的时候对返回结果没有做脚本处理，返回了一些恶意的js脚本，而我们对大模型返回的结果可能直接执行了，简单点说就是 el.innerHTML = content。我们都知道使用这种形式，如果content里面包括了script脚本，也会自动执行的，这种攻击其实有个专业名词XSS攻击漏洞。

按照这种思路，显示询问了大模型的后段有没有这种可能性，后端给出了很明确的回复，概率很小，不太会将js脚本直接返回到大模型的输出接口中。另一方面，我们也看了前端项目的工程，发现也没有类似innerHTML的这种写法，我们对返回的内容已经做了script标签转义处理，即仅仅在界面显示script文本字符串，通过这种处理方法来绕过XSS攻击。

即然不是这个原因，那有没有可能是我们项目的js脚本或者html页面被攻击了，被恶意注入了js脚本，但是这种可能性应该也不大，为什么这么说呢？首先这个项目已经上线很久了也是最近才有这个问题，第二我们的页面已经使用https攻击，要被拦截还是有一定难度的。

到了这里，似乎已经没有其它可能性，我也暂时的陷入到了迷茫当中，突然一位同事和我提了一嘴，他说会不会是我们引用的vconsole这个cdn资源被攻击了呢？因为最早这个项目是用ai生成，ai给出的就是直接引用了一个线上bootcdn下的vconsole服务，这个cdn很早之前我就了解到，第一反应觉得概率应该也不大，但是看了下返回的内容后，顿时惊呆了，这个文件的末尾追加了一段莫名其妙的代码，这里为了安全就不把代码贴出来了。

简单讲下这段代码做了什么：

有一个加载script标签的操作，入参是一串base64后的字符串，这里其实就是一个障眼法，防止被人直接搜索到或者识破
有一段加载触发的判断条件，首先平台不能是Mac和win，那便是定位于移动端，除此之外还要求页面必须是从另外页面跳转过来，即document.refer需要有值，这也恰好证明了为什么我们在pc端就没有复现的现象

再来看看上述这段加载的js内容，打开一看全是混淆后的代码，拿着这段代码问了下ai，发现内部发起了一个post请求，对返回的内容直接js执行，再来看看这段post请求返回的内容，就是一个跳转到另外一个页面的操作。

至此，整个流程完全梳理清楚了，那我们也很简单的就处理好了这个问题，将引用的第三方cdn资源直接替换为本地的资源。

结论

我们这里不讨论bootcdn这个资源是怎么被拦截攻击的，我们这里要讨论的是使用这种公共的第三方js资源库目前看来是存在很大风险的，最好还是将这些资源存储到本地来使用，如果你也遇到了类似的问题，可以马上检查下是否有相似的引用外部资源的情况，如果有的话即使进行替换修复即可。