034-一个 Chrome XSS Filter Bypass 的分析

[Start Tag (div)][Characters (aaa)][Start Tag (img)(attr: {src: x})][Start Tag (script)][Characters x=1;][End Tag (script)]

“`

首先解析器读取到 [Start Tag (div)]，判断没有危险；接下来读取 [Characters (aaa)] ，也没有危险；然后读取 [Start Tag (img)(attr: {src: x})] ，过滤器将会检查 src 属性是否以 javascript: 开头，这里不是，同样没有危险；之后检查 [Start Tag (script)]，这里过滤器将会到 URL 中找 script 字样，来确认 URL 是否有引入脚本的可能；并且从这里开始进入了 script 标签内部，过滤器会对此进行标识；之后到了 [Characters x=1;] ，注意到这里已经到了 SCRIPT 标签内部了，因此，过滤器将会拿 “x=1;” 在 URL 中搜索，这也是文章开头的 Patch 中出现的代码:

“`
– if ((m_state == SuppressingAdjacentCharacterTokens)
– || (m_scriptTagFoundInRequest && isContainedInRequest(canonicalizedSnippetForJavaScript(request)))) {

“`

0x02 漏洞分析
=========

* * *

这里我们先不管这个 Patch 是如何修复的，我们先来分析漏洞的成因。

PoC 中的注入代码将会解析成怎样的 token 序列呢？

“`

“`

是这样么?

“`
[Start Tag (svg)][Start Tag (script)][Characters /<1/>alert(0)][End Tag (script)]

“`

如果是这样， XSS Filter 是无法绕过的。

在这里，由于是在 SVG 标签内部，词法解析器将会考察每一个 “<" ，当在字符状态中出现 "<" 时，即意味着进入了一个新的标签，词法解析器会将之前的字符串作为一个单独的 token 提取出来处理掉，再来处理这个新的标签。但是这里，`<*/>`并不是一个合法的标签，当解析器处理时，不得不退回，将其当作新的字符串处理。

因此真正的 token 序列是这样的：

“`
[Start Tag (svg)][Start Tag (script)][Characters /][Characters <1/>alert(0)][End Tag (script)]

“`

重复上述的过滤器过滤流程，在考察过 SCRIPT 开始标签后，过滤器将会处理随后的字符串。处理函数(补丁前)如下：

“`
bool XSSAuditor::filterCharacterToken(const FilterTokenRequest& request)
{
ASSERT(m_scriptTagNestingLevel);
ASSERT(m_state != Uninitialized);
if (m_state == PermittingAdjacentCharacterTokens)
return false;

if ((m_state == SuppressingAdjacentCharacterTokens)
|| (m_scriptTagFoundInRequest && isContainedInRequest(canonicalizedSnippetForJavaScript(request)))) {
request.token.eraseCharacters();
request.token.appendToCharacter(‘ ‘); // Technically, character tokens can’t be empty.
m_state = SuppressingAdjacentCharacterTokens;
return true;
}

m_state = PermittingAdjacentCharacterTokens;
return false;
}

“`

先处理 “/”，处理函数为`canonicalizedSnippetForJavaScript`；然后看处理后的结果是否在 URL 中(`isContainedInRequest`)并且是否 URL 中存在 script 标签(`m_scriptTagFoundInRequest`)；如果不在，则设置当前状态为`PermittingAdjacentCharacterTokens`，即认为它是没有危险的。

接下来处理 “`<1/>alert(0)`”，但是注意到处理函数中，首先检查了状态是否为 PermittingAdjacentCharacterTokens ；这里因为两个字符串 token 是连续的，因此，如果第一个字符串没有检测到在 URL 中，那么第二个字符串根本就不会被过滤！因为当前状态已经被设置为`PermittingAdjacentCharacterTokens`了！

而这个 PoC 则正是利用了这一点。对于 “/”， 在被`canonicalizedSnippetForJavaScript`处理后，将会变成空字符串！而空字符串是不会被认为与 URL 中的子串重复的。

为什么会变空呢？`canonicalizedSnippetForJavaScript`会对传入的 Javascript 代码作一系列处理，其中会调用`isNonCanonicalCharacter`函数检查字符串，将匹配到的字符删去。匹配代码如下:

“`
return (c == ‘\\’ || c == ‘0’ || c == ‘\0’ || c == ‘/’ || c == ‘?’ || c >= 127);

“`

“/” 正在其中。

两个字符串结合起来，即`/<1/>alert(0)`是一个合法的 Javacript ，可以成功执行。

类似的，我们可以自己构造其他 PoC :

“`

“`

这里利用了 “0” 也会被处理为空字符串的特性。

如果构造成

“`

“`

能否绕过呢？

答案是否定的，当进入其他标签时，当前状态将会设置为`FilteringTokens`，无法绕过检查。

因此，这个绕过利用了 SVG 内标签的特殊解析模式，过滤器的连续过滤的机制，以及`isNonCanonicalCharacter`函数对几个特定字符的匹配后清除。显然，攻击者是看着 XSSAuditor 的源码构造的 PoC。

：）

**_其实，这里`canonicalizedSnippetForJavaScript`是很复杂的，因此，可能存在其他方法使得第一个字符串被认为是允许的(即不在 URL 中)。也正是因为这个，在 Patch 的说明中，最后有一句 “Keep looking in that case.”，有可能还会出现类似的绕过。_**

0x03 补丁分析
=========

* * *

补丁其实很简单，如果某个处理后的字符串为空，则既不设置为允许也不设置为禁止。这样既不会干涉后面的处理，也不会增加误判。

具体补丁代码不再分析，其实就只有上面这一点差别。