漏洞风险：可以在其他应用借助小宇宙端内跳转任何网页。

此文章发布前，小宇宙已经修复了这个问题，所以你们可能不能复现这个问题了。

先看漏洞效果，这个漏洞的问题是你可以在小宇宙里跳转到任何网站，甚至是 PornHub。不过这个 Bug 不重要，重要的是发现 Bug 的过程。

0. 背景

在一天晚上，我在和朋友聊小宇宙的 URL Scheme，想要做个功能，可以实现一键打开小宇宙的节目页面。但卡在我面前的是，我不知道小宇宙的 URL Scheme 到底是什么。于是便开始了我的 Hack 之旅，也就找到了小宇宙的这个安全漏洞。

1. 找到小宇宙的 URL Scheme

由于 Scheme 是在 App 中定义的，所以当我想到要找 Scheme 之后，第一反应的是去拿 iOS App 的 Info.plist（因为 iOS 是将 Scheme 定义在 info.plist 当中）。

过去需要通过 IPA 备份、越狱等方式来获取到这个文件，不过得益于 M 系列支持在 macOS 上运行的原因，现在 IPA 的获得变得非常的简单。 先在 App Store 安装小宇宙，并在「应用程序」中找到小宇宙。

然后右键点击小宇宙，点击「显示包内容」

然后看到这样的内容，WrappedBundle 是一个假的应用程序，所以继续点击 Wrapper 往里跳转。

然后会发现里面还有一个 Podcast 应用，这个才是真正的小宇宙的 IPA 包。然后继续点击「显示包内容」

在包内容当中可以看到 info.plist 文件，使用 Xcode 或者 VSCode 打开 info.plist 文件。

在 info.plist 文件中，搜索 CFBundleURLSchemes ，找到了小宇宙的 URL Scheme（里面有很多个，但很多都是其他应用的，试一下就可以发现）：cosmos://。

2. 找到 URL Scheme 能够打开的页面

找到了 URL Scheme，只能通过 cosmos:// 打开应用首页，无法满足我的需求，于是开始继续寻找可能的 URL Scheme 。一般来说，这个时候就只能继续反编译 IPA 包或者 APK 包了。不过对于我来说，这些不是一个好的选项（成本太高）。

然后想到，小宇宙的网页似乎是提供了打开客户端的能力，所以可以从网页版找到突破口。通过简单的搜索，果然让我在网页前端找到了突破口。找到了 7 个 Scheme 。

当然，中间存在一些重复的 Scheme。所以最终梳理出来的 Scheme URL：

• cosmos://page.cos/discover:打开发现页
• cosmos://page.cos/shownotes/EPISODE_ID：打开节目的 Shownote 页面
• cosmos://page.cos/episode/EPISODE_ID：打开节目的详情页
• cosmos://page.cos/webView?url=：意义不明，看起来像是打开一个特定的 URL
• cosmos://page.cos/web?url=:意义不明，看起来像是打开一个特定的 URL

3. 发现问题 URL Scheme

前面的三个很正常，但后面的两个带 URL 的引起我的注意 —— as a Hacker，你知道的，任何一个可能的输入框都可能成为我们的注入点，于是乎，我就构建了一个链接，来打开我的 Blog

cosmos://page.cos/web?url=https%3A%2F%2Fwww.ixiqin.com
Code language: JavaScript (javascript)

将这个链接使用 Safari 打开，就会自动唤起小宇宙，并打开我的播客。

至此，我发现了小宇宙这个跳转注入漏洞，并快速将其反馈给小宇宙官方同学。

复盘：如何规避这样的问题

在这个 Case 当中，小宇宙因为没有设置 URL 跳转的白名单，导致实际上出现了跳转恶意网站的风险。理论上，作为应用提供商，出于安全合规的视角，最好是控制 URL 跳转的域名和空间，避免被恶意滥用。

或者也可以参考我们现在见到的很多网站，在外部跳转时加一个风险提醒。

如果在这个 Case 当中，小宇宙在一开始就限制了可以打开有限域名，那也不会出现如今我这次的漏洞问题。

这个问题风险大么？

取决于如何定义和如何使用。如果只是跳转一些常规网站，自然是风险不大的。但如果不受限制的，比如跳转到一些诈骗网站，可能风险就是大的。

在 使用 Caddy 处理 WordPress 当中，我提到在用 Caddy 处理 WordPress，且为了性能做了很多优化。

我的博客经历了三重优化：最基础的 PHP OpCache + Redis 数据查询缓存 + 静态化缓存。

其中一个比较有效的，便是在整个站点上加入静态化缓存，绝大多数游客看到的其实是预先生成好的静态页面，从而减少了数据库加载、渲染、计算的成本。

而想要实现静态化，则需要借助于 Cache Enabler 插件和 Caddy 配置来完成。

安装插件并启用

安装 Cache Enabler 插件，并启用插件，启用后，在后台设置中，配置过期时间和对应的清除策略，并保存。这个时候，Cache Enabler 就会自动帮你去生成不同的页面了。

配置 Caddy 路由转发

首先，你应该在你的 php_fastcgi unix//run/php/php-fpm.sock 前面加入缓存的代码并重启 Caddy，具体如下

缓存配置如下

     @cache {
		not header_regexp Cookie "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"
		not path_regexp "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(index)?.xml|[a-z0-9-]+-sitemap([0-9]+)?.xml)"
		not method POST
		not expression {query} != ''
    }

    route @cache {
        try_files /wp-content/cache/cache-enabler/{host}{uri}/https-index.html /wp-content/cache/cache-enabler/{host}{uri}/index.html {path} {path}/index.php?{query}
    }
       
Code language: JavaScript (javascript)

这部分配置先定义了一个 @cache 块，用于后续判断，并在其中加入了多种条件判断，说明了不使用缓存的情况：

• 如果用户有以下 Cookie，就不使用缓存：
  • comment_author（评论作者）
  • wordpress_[a-f0-9]+ （WordPress 的会话 Cookie）
  • wp-postpass（密码保护文章的 Cookie）
  • wordpress_logged_in（登录状态的 Cookie）
• 如果当前请求命中了以下路径则不缓存
  • /wp-admin/（后台管理页面）
  • /xmlrpc.php（XML-RPC 接口）
  • 所有 wp-*.php 文件（WordPress 系统文件）
  • /feed/（RSS 订阅）
  • sitemap 相关文件
• POST 请求不缓存（比如评论）
• 带查询参数的缓存不请求。

随后，通过 route @cache 定义了命中缓存部分的查找顺序：

1. 先找 HTTPS 版本的缓存：/wp-content/cache/cache-enabler/{host}{uri}/https-index.html
2. 再找普通缓存：/wp-content/cache/cache-enabler/{host}{uri}/index.html
3. 如果找不到缓存，就尝试原始路径：{path}
4. 最后尝试 PHP 文件：{path}/index.php?{query}

查看效果

打开一个无痕窗口，访问你的网站，如果在 html 底部看到 <!-- Cache Enabler by KeyCDN @ Sat, 04 Jan 2025 03:05:34 GMT (https-index.html) --> ，则说明你已经成功启用静态化缓存了！

参考资料

• 如果你使用 WP Supercache 、 WP Rocket、WP Fastest cache、W3 Total Cache，则可以参考 https://caddy.community/t/example-configure-wordpress-with-a-static-cache/8215 进行相关配置。