XSS Attacks - Exploiting XSS Filter

最新推荐文章于 2024-08-18 19:04:11 发布

Sword-heart

最新推荐文章于 2024-08-18 19:04:11 发布

阅读量229

点赞数

文章标签： web安全网络安全安全 hack wooyun

本文链接：https://blog.csdn.net/jd_cx/article/details/124442105

版权

本文详细剖析了IE浏览器的XSSFilter机制存在的问题，指出其在防止XSS攻击时可能出现误杀正常内容的情况。通过具体例子展示了由于正则表达式的匹配不当，导致原本无XSS漏洞的页面变得易受攻击。同时，文中揭示了正则存在交集，使得某些防护策略失效，从而引发安全风险。修复方案包括关闭x-xss-protection或使用1;mode=block策略。

摘要由CSDN通过智能技术生成

0x00 前言

这又是一篇来自全职赏金猎人Masato kinugawa的神作。一次双杀，用一篇报告拿下了两个CVE，分别是CVE-2015-6144和CVE-2015-6176。报告内容指出IE的XSS Filter在对XSS攻击进行屏蔽时，由于正则的匹配不当在一些场景下会让本不存在XSS漏洞的页面产生XSS漏洞的问题。

0x01 IE的XSS Filter

Internet Explorer自IE8开始也就是2009年左右的时候首次导入了XSS Filter这一机制。不得不说，XSS Filter让很多安全研究者头疼。因为有时候你还真的就绕不过去。这会让我们产生兴趣说XSS Filter到底是怎么去阻挡xss攻击的。说简单也简单，IE会去比对用户的request和response如果IE认为有害的内容同时出现在了request和response当中，IE就会选择屏蔽掉response中部分xss关键字。（根据情况有时候会屏蔽整个response body）举个例子，如果你用IE像example.com发送如下的请求：

<code>#!html

http://example.com/?q=<img src=x onerror=alert(1)>

</code>

那么你看到的response body就会是这样：

<code>#!html

q param is : <img src=x #error=alert(1)>

</code>

onerror变成#nerror后这段html确实没有办法执行JavaScript也就谈不上什么XSS攻击。看似非常合理，其实设计上存在非常的大的问题。问题的核心在于IE不会去管response body中出现与request相匹配的内容是原始的response内容还是攻击者发送请求后所增加的内容。可能说的有点绕口，所以我得再举个例子。假设你像example.com发送如下的请求:

<code>#!html

http://example.com/?q=AAA&<meta charset=

</code>

即便你没有任何参数（不难想到不看参数是在防范HPP攻击）它也会毅然决然地把原始的meta tag给屏蔽掉。所以response body会变成这样:

<code>#!php

<m#ta charset=“utf-8”>

</code>

一次完美的误杀。这也是这两个CVE所利用到的IE的特性之一。居然说到了之一，就肯定有之二。之二是什么呢？之二就是负责防守不同场景下的XSS的正则在特定情况下，产生了交集。所以在这里我得再再举个例子来说明这个问题。在IE负责虐杀XSS的mshtml.dll当中有这么一段正则：

<code>#!bash

[ /+\t\"\'`]style[ /+\t]*? =.*?([:=]|(&[#()\[\].]x?0*((58)|(3A)| (61)|(3D));?)).*?([(\\]|(&[#()\[\].]x? 0*((40)|(28)|(92)|(5C));?))

</code>

这个正则是用来防谁的呢？就是下面这段xss攻击：

<code>#!php

<p style="x:expression(alert(1))">

</code>

这里的[ /+\t]*?会匹配style和=之间出现多余0的空白字符（0x09-0x0D,0x20,/,+）。看似没有问题，然而研究者再次发现url中出现的“+”可以被任意的[0-6]byte的html内容所匹配。

也就是说当我们对下面的页面发送类似这样的请求URL:?/style++++++=++=\时

<code>#!html

<style> body{background:gold} </style>

</head>

<body>

<input name="q" value="">

</code>

由于URL中的”+”可以被看作是任意的[0-6]byte的html内容，所以从style结束到第一个等号开始的31 bytes内容会被[ /+\t]*?匹配上。浏览器认为这是一次类<p style="x:expression(alert(1))"> 攻击，毫不犹豫的把style替换成st#le，response body再一次变成: