微信小程序源码包泄露？这个锅要 CDN 来背

导读：

微信小程序源码包泄露，罪魁祸首竟是 CDN ？微信的 CDN 服务提供商这次要背锅咯。

今天一大早，在 V 站看到了这样的一篇帖子《微信跳一跳可以直接更改分数，POST 请求没有校验…》

点进去发现有这样一段文字：

竟然可以下载微信小程序的源码？这岂不是所有的小程序任意被 Copy 了？开发小哥哥 247 的工作成果就这样被人任意下载了？太坑了吧！

出于云计算从业者的敏感，我认为，这次的锅，可能要微信的 CDN 服务提供商来背了。

接下来来说说原因。

域名泄露天机

在我上面的截图，你可能会看到下载的 URL，这个 URL 的前半部分是这样的，

123.125.9.32/resstatic.servicewechat.com/

如果是一个云计算从业者，看到这样的 URL 可能立马就非常敏感了，因为这种 URL 是很典型的 CDN 检测链接，CDN 的用户可以用这个链接来检测自己的服务是否被部署到了对应的节点上。这个 URL 就是检测，域名 resstatic.servicewechat.com 部署在 123.125.9.32 节点上的数据是否已经部署成功，如果你访问的目标文件存在，则说明 CDN 节点成功的缓存了对应的源站数据。我们通过了这个测试链接获取到了 CDN 节点缓存的内容。

诶，虽然上面你说的我好像听懂了，但是还是没明白为什么锅要 CDN 背啊，这个锅不应该是甩给微信开发团队的么？

嗯，话是这么说，URL 的泄漏肯定和开发团队写的代码有关，但是这个问题的核心在于使用的 CDN 没有提供相对应的功能支持，从而导致了最终的泄漏。如果 CDN 层面上搞定了功能，即使开发者在上线前没有注意到替换对应的地址，也不会出现问题的。

CDN 到底是个啥？

接下来，我们来说说，到底什么是 CDN，来帮助你理解为什么锅我们要甩给 CDN。

CDN 的全称为 Content Delivery Network，中文的含义是内容分发网络。这里的重点是，网络，这说明 CDN 并不是一个单机结构，而是有很多不同的节点累计出来的。

在没有使用 CDN 之前，我们的网站是这样被访问的

无论你是来自中国东北，还是美国俄勒冈，又或是浪漫之都巴黎，你想要访问我的网站，都需要访问我放在 FoShan 的服务器。

我们都知道，虽然说光速很快，但是我们的电子的传递速度有限，受到物理条件的限制，也就导致不同的地区到达同一个地点的速度有快有慢。

对于来自东北的老铁，访问我的网站自然是速度还不错。
俄勒冈的美帝男青年，得益于中美的海底光缆，速度还行。
但是法国巴黎的妙龄女郎就遭了殃，她想要访问我的网站，数据包要先从 FoShan 经由中美海底光缆，达到美国后，再通过美国和欧洲的海底光缆，到达欧洲、到达法国，这位妙龄女郎想要访问我的网站，就要等待很久，连连说 Non。

作为一个商人，我不希望丢失来自法国的订单，但是现实却是法国人访问我的网站变成了“ World Wide Wait （世界一起等待）”。如何解决这个问题呢？

在 1995 年，美国麻省理工学院的一位应用数学教授 Tom Leighton 博士借助应用数学和运算学解决了这个问题

上图就是发明了 CDN 技术的 F. Thomson Leighton 老爷子，他和当时一起研究 CDN 技术的几位顶级研究人员创建了世界上第一家，也是迄今为止最大的 CDN 公司 Akamai。

他们是如何解决这个问题的呢？

你不是离目标网站远么？我让目标网站离你近一点，你访问速度不就快了么？

他们在全球部署一系列不同的节点，构建一层虚拟网络（就是我们说的「内容分发网络」），并借助算法，实时的根据网络流量和节点的连接、负载情况以及到用户的距离和响应时间等综合信息，将用户的请求重新导向离用户最近的节点。

经过这么一导，原本你要访问 FoShan，才能看到的网站，现在你只需去伦敦就够了，节省了大段的路程，访问速度自然快了。

为什么能够分配到对应的节点？这个得益于 CDN 的核心技术，流量分发算法。我唔知啦！

事实上，真实的场景下，可能不只有 LA、DaLian、Londo 这三个节点，而是世界各处都有，用户访问的时候可能根本不需要跨国、跨地区，你所在的城市就有节点，隧道相当快。

你可能会问，为什么访问他的节点，就和访问我的站点一样？

这是得益于 CDN 工作的机制，当用户初次访问 CDN 节点时，CDN 节点会检测，自己有没有对应的文件的缓存，如果没有，则会向源站请求这个文件。第一次访问 CDN 时，速度会略慢于不加 CDN。因为用户需要经过 1234，四步才能获得文件。

当用户第二次访问 CDN 节点时，CDN 检测到自己有对应的文件。就直接讲对应文件返回给用户。第二次访问时，速度会非常快，远胜不加 CDN。因为这次用户访问时，只需要和 DaLian 的 CDN 节点进行沟通，就可以了。

得益于距离的缩短，CDN 使我们的资源访问的速度变得飞快无比。借助于海量的 CDN 节点，我们的网站能够背全世界人民以相当快的速度来访问。

没有校验的 CDN 如同不设防的宫殿

上面，我们了解了 CDN 的工作原理，接下来我们回到微信这次的问题上。在上面我们提到，CDN 为了提升我们的资源的加载速度，会将我们的内容缓存在 CDN 节点上。

由于我们的内容很多时候得到授权才能看的，所以不少 CDN 进化出了一项新的功能，URL 鉴权。URL 鉴权就是我们的请求地址后面，加入一个形如?auth_key=timestamp-rand-uid-md5hash的参数，通过这个参数的校验，来实现访问的控制，参数校验通过，正确返回内容，校验不通过，报错。

当用户请求中的 Auth Key 不正确或不存在时，则返回 401 Unauthorized。这样，就保证了我们的请求在未经授权下，无法被访问到。

在微信的抓包结果中其实也可以看到，下载小程序的源码包是加了参数的。

但是很不幸的是，可能是微信小程序的 CDN 服务商并不提供相关的功能，导致我们可以通过 CDN 的校验地址直接下载小程序的源码包。当然，也可能是该服务商并没有在该功能上加入 URL 鉴权的控制，所以就坑了微信一把。

国内都有哪些 CDN 服务提供商支持 URL 鉴权？

目前，国内 CDN 服务商林立，老牌子的网宿、蓝汛；云计算服务商阿里云、腾讯云、百度云、又拍云、七牛云；安全服务提供商安全宝、360 网站卫士等等。其对 URL 鉴权的支持度也不同。具体的你可以看下面的表格。

总结

微信的 CDN 服务商不知是哪家，希望能够尽快加入相关链接的校验。对于我们来说，我们得到了一个教训，CDN 上存放的内容，应该进行 URL 鉴权，以确保数据的安全！特别是源码等重要的内容。

本文仅代表我个人的观点，如观点有误，欢迎指出！