【最新漏洞预警】CVE-2022–21662 WordPress核心框架存储型XSS漏洞分析与复现

关注公众号回复“漏洞”获取研究环境或工具

接着前面分享的WordPress Core SQL注入漏洞CVE-2022–21661：

WordPress Core SQL注入漏洞CVE-2022–21661

QCyber，公众号：且听安全【最新漏洞预警】CVE-2022–21661 WordPress核心框架WP_Query SQL注入漏洞原理分析与复现

下面继续分析通报中的CVE-2022-21662漏洞：

从描述来看，这是一个存储型XSS漏洞，影响`posts`模块的`slug`参数。

添加一个新的`posts`：

提交抓包，并加入调试配置：

`Slug`对应参数`post_name`。请求进入`wp-includespost.php`的`edit_post`函数：

继续往下走，进入`wp_insert_post`函数，从第3977行开始，将对参数`$post_name`进行检查：

进入`sanitize_title`函数：

利用过滤器`sanitize_title`进行处理，`sanitize_title`定义位于`default-filters.php`中：

定位`sanitize_title_with_dashes`函数：

限制非常严格，更换`$post_name`参数为XSS Payload测试，发现特殊字符都被过滤了。

根据`sanitize_title_with_dashes`代码处理特点，继续修改参数，加入URL编码，再次请求`sanitize_title_with_dashes`函数将不会进行处理：

继续往下走：

进入`wp_unique_post_slug`函数，在第4838行将尝试查询数据库：

这里将尝试取出`$post_name`相同但是`$post_ID`不同的`$post_name`，并赋值给`$post_name_check`，继续往下走到第4879行，当`$post_name_check`非空时，将调用`_truncate_post_slug`函数：

进入`_truncate_post_slug`：

这个函数非常有意思，当`$slug`（也就是`$post_name`）长度大于200时，首先会完成一次URL解码，然后再尝试调用`utf8_uri_encode`完成URL编码。

从上面分析过程可以看出，要进入`_truncate_post_slug`，需要满足2个条件：

• 需要将XSS Payload赋值给一个`posts`的`slug`，然后新建一个`posts`保证`slug`相同

• XSS Payload需要加入一些冗余数据，保证长度超过200

为了方便进一步分析，我们首先构造一个可以进入`_truncate_post_slug`函数的例子，再新建一个名为`test2`的`posts`，将`slug`赋值为：

%22%27%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

然后将`test`的`slug`修改为与`test2`相同，此时再次发送请求将顺利进入`_truncate_post_slug`:

经过URL解码后，进入`utf8_uri_encode`：

发现`utf8_uri_encode`并不会对字符进行编码，参数取值仍然为XSS Payload，导致最终出现XSS漏洞：

调用`utf8_uri_encode`函数时，将`$encode_ascii_characters`参数显式赋值为`true`：

这样所有的字符都会进行URL编码，输出如下：

从而导致XSS无法触发。

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，且听安全团队及文章作者不为此承担任何责任。

点关注，不迷路！

关注公众号回复“漏洞”获取研究环境或工具