迹忆客 专注技术分享

WordPress 4.1.2 于 2015 年 4 月 21 日可用。WordPress 4.1.1 及更早版本受到严重的跨站点脚本漏洞的影响，该漏洞可能使匿名用户破坏站点（WP 博客）。

简介：MySQL严格模式

去年年初，我正在阅读一篇关于 MySQL 的 utf8 字符集如何仅支持 3 字节字符的博客文章。 如果你喜欢 PILE OF POOs（我指的当然是角色），我建议你也阅读这篇文章。 简而言之：根据 RFC3629，以 UTF-8 编码的字符在技术上的长度可以在 1 到 4 个字节之间。 如果你真的想存储 4 字节的字符，你需要一个 utf8mb4 字符集。

当我们将包含 4 字节字符的字符串插入 utf8 列时，默认的 MySQL 行为是在（包括）4 字节字符出现后截断字符串的其余部分。 这可以通过使用 MySQL 的严格模式来防止，该模式确保数据在存储之前有效。

严格模式控制 MySQL 如何处理数据更改语句（如 INSERT 或 UPDATE）中的无效或缺失值。 一个值可能由于多种原因而无效。 例如，列的数据类型可能有误，或者可能超出范围。 如果严格模式未生效，MySQL 会为无效或缺失值插入调整后的值并产生警告。

在这种情况下调整后的值是截断的字符串。 我应该提一下，MySQL 不仅对 4 字节字符显示这种截断行为，而且对所有字符集都显示无效字节序列，这意味着 utf8mb4 和更奇特的字符集一样容易受到攻击。 唯一的例外是 latin1，它几乎可以接受任何东西。 为防止这些截断问题，我们必须在与 MySQL 服务器建立连接时手动启用 MySQL 严格模式，因为默认情况下未启用。

• 示例（插入前）：ex𝌆tic
• 示例（插入后）：ex

我想知道如何将这些知识用作可能的攻击媒介。 MySQL 未处于严格模式时的行为让我想起了过去弹出的许多空字节漏洞。 当数据截断在起作用时，事情就会出错。

这如何影响 WordPress

我开始选择将成为我的受害者的 Web 应用程序来尝试这种行为。 一些项目在建立数据库连接时启用了 MySQL 严格模式。 WordPress 没有启用严格模式。 完美的。

我不必看得很远。 WordPress 的核心评论功能似乎截断了我制作的字符串！ 默认情况下，放置评论是在 WP 核心中处理的，尽管 Disqus 等插件可以替代此功能。

此外，我们可以在评论中使用一组有限的 HTML 标签：<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite="" > <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

• 友好的用户可以评论：<abbr title='Web log'>blog!</abbr>
• 不太友好的用户可以评论：<abbr title='Web𝌆log'>博客！</abbr>

两条评论都通过了 WordPress 的输入验证器，但只有第一条被正确存储。 第二个存储为 <abbr title='Web。 此注释有效地破坏了 HTML 页面的良构性，因为结束引号和标记标记不存在。

现在想象一下，如果我们在精心设计的用户名下发表另一条评论会发生什么，例如：cedric' onmouseover='alert(1)' style='position:fixed;top:0;left:0;width:100%;height:100 %'

成功提交两条评论后，HTML 输出将如下所示：

<div class="comment" id="comment-1">
    <div class="comment-author">
        Testing
    </div>
    <div class="comment-content">
        <p>
            <abbr title='Web
        </p>
    </div>
<div class="comment" id="comment-2">
    <div class="comment-author">
        cedric' onmouseover='alert(1)' style='position:fixed;top:0;left:0;width:100%;height:100%'
    </div>
    <div class="comment-content">
        <p>
            Injected
        </p>
    <div>
</div>

结果我们得到以下 HTML：

<abbr title='Web......cedric' onmouseover='alert(1)' style='position:fixed;top:0;left:0;width:100%;height:100%'>

一旦受害者将鼠标悬停在该元素上，这段代码将有效地导致脚本执行。 此技术仅在评论文本和作者姓名之间没有其他单引号时有效，因此取决于当前的 WordPress 主题。

对输出进行优化

现在，如果上面的方法太难了，似乎还有另一种方法。 只要我们的评论包含换行符，就会发生某种输出清理，将引号字符替换为 “。

这意味着提交以下有效负载就足够了：

sometext

<blockquote cite='x onmouseover=alert(1) 𝌆'>

我们现在的脚本执行不再依赖于当前的 WordPress 主题，因为引号被转义了。

<blockquote cite=&#8220;x onmouseover=alert(1) ...>

载荷截图：

有效载荷可以以受害者不可见的方式制作。 当受害者现在到达评论页面时，将执行脚本。 作为概念证明，我创建了一个有效负载，将新用户添加到管理面板，这意味着我们需要管理员才能访问注入的评论页面。 下载和安装执行恶意服务器端代码的插件也可以这样做。 我现在不会分享 PoC，因为它丢失了（见下文……）。

一些限制因素

该漏洞仅影响某些字符集。 如果我们对数据库中的列使用 latin1 字符集，则可能是安全的。 然而，utf8 是 WordPress 中的默认设置，现在已更改为 utf8mb4 并且具有几个优点。

值得注意的是，在默认设置中，评论需要得到管理员的批准。 虽然（也是默认情况下），当我们的第一条评论获得批准时，下一条评论不需要批准

请注意 ，数据截断不仅会影响评论功能，还会影响所有 WordPress 核心和插件。 我们应该以任何一种方式升级您的 WordPress 版本。 因此，可能存在许多其他尚未发现的攻击媒介。 例如，在写这篇博文时，我不小心插入了一个无效的字节序列*叹息*，将文章截断了一半。

解决这个问题

解决这个问题是一个漫长的过程。 由于它影响了数据库层的 WordPress 核心，因此必须对修复程序进行彻底测试，以确保各种设置中的网站仍能按预期工作，无论它们使用的是什么字符集。 WordPress 被编写为在任何具有 PHP 和网络服务器的系统上运行，无论安装的功能如何。 因此，安装 WordPress 轻而易举，但开发需要引入复杂的案例以确保（向后）兼容性。 进行了测试以查看是否可以在 WordPress 中启用严格模式，但后来又恢复了，因为它破坏了与太多插件的兼容性。

早在 2014 年 10 月，补丁代码的点点滴滴就被推送到 VCS 主干。这意味着我们不太可能在 4.1.1 版（以前的 WordPress 版本）上成功执行 XSS。

我相信很多网站都容易受到这种存储型 XSS 漏洞的影响。 福布斯网站提到，2012 年有 6000 万个 WordPress 网站，而且这个数字每天都在增加。 如果 60 个网站中只有一个易受攻击，那么仍有超过 100 万个网站可供利用。 值得庆幸的是，WordPress 有一个自动更新机制，所以如果我们是博客所有者，我们现在可能已经安装了补丁。