在本文中，我将描述最近在w w.google.com中发现的另一个XSS错误。这次它只在由主机头反映的XSS中处于活动状态。
在自定义搜索引擎（CSE）中发现错误。这是谷歌在2006年推出的一项服务，允许你对搜索页面进行个性化设置，并将搜索限制在自己的域名内。
Internet Explorer和主机头操作
以下Internet Explorer中描述的错误是由Sergei Beaver（化名Black2Fan）发现的。2013年3月，微软向微软报告了这一情况，当时微软还确保在下一个版本的IE中更正错误。然而，在IE11中，问题仍然存在。
Internet Explorer有一个非常具体的行为，与重定向中位置头的解释相关。这导致在其他浏览器中操作主机头的异常能力。
让我们记住默认情况下路由服务器响应是什么样子。
HTTP/1.1协议
日期：自由，2015年3月6日08:30:23 GMT
服务器：Apache/2.2.22（Debian）
X电源：PHP/5.4.36-0+deb7u3
位置：http://example.com/login.php
变化：接受编码
内容长度：0
连接：关闭
内容类型：text/html
最重要的是带有Location头的5行，因为它包含资源上的浏览器发送下一个请求的信息。
IE行为分析表明，该浏览器通过将所有内容放在http:/、下一个slasha符号（/）或主机头中的行尾之间来构建另一个请求。在本例中，这将是example.com。听起来这是正确的做法。然而，我提出了一个小小的谜团：当Internet Explorer收到以下答案时，他会怎么做？
HTTP/1.1协议
日期：自由，2015年3月6日08:35:32 GMT
服务器：Apache/2.2.22（Debian）
X电源：PHP/5.4.36-0+deb7u3
位置：http://example.com%2flogin.php
变化：接受编码
内容长度：0
连接：关闭
内容类型：text/html
/sign已转换为其在%2f URL编码中的表示形式。原则上，浏览器不应响应此重定向发出任何请求，因为位置头的值显然不正确。这就是其他流行浏览器（Chrome、Firefox）的表现。而Internet Explorer则发送另一个请求，其中包含非常有趣的内容。
GET/login.phphp/HTTP/1.1
接受：text/html，application/xhtml+xml*/*
接受语言：pl pl
用户代理：Mozilla/5.0（Windows NT 6.3；WOW64；Trident/7.0；rv:11.0），类似于Gecko
接受编码：gzip，deflate
主机：example.com/login.php
DNT:1个
连接：保持活动
缓存控制：无缓存
真 的。原来IE在主机头中放了一个URL编码的字符串格式，之前是从位置头下载的！此外，“奇怪”填充了请求的第一行，因为如果请求中没有这样的字符串，login.phphp从何而来？错误页面上错误检测器的描述显示IE在自身上放置两种形式的查询：执行URL解码之前和之后的字符（图1）。
图一。如何在IE中建立一条路径
当然，如果XSS在没有加密的情况下写在某个页面上，则可以使用允许在主机头中插入任何字符串的错误来执行XSS。
总之，如果我们向http://Location:http://example.com%2F<script>alert（1）<%2fscript>发送回复，并且此标题的值将写入应答中的某个位置，那么我们就有XSS。
然而，在实践中，我们可以期望服务器对应400个错误的请求代码，因为这样的主机头显然是不正确的（图2）。
图二。服务器对应于“奇怪的”主机头代码400
在Google服务器中管理主机头
谷歌服务器，正如我在图2中所示。他们不喜欢在主机头中被发送非字母数字字符。我开始想办法解决这个问题。解决方案是端口号，如您所知，您可以在来宾名称和端口号之后添加一个double，例如。邮箱：1024。经过两步处理后，Google服务器没有验证这些值，所以我可以在那里写任何我想写的东西，我立即设法在网站上找到了几个写主机头的地方。不幸的是，加密；）
图三。在主机头和Gmail回复中插入您自己的字符
所以我需要找一个地方，在那里加密是不可能的。然而，在我开始之前，我将再描述一个我需要利用漏洞的Google服务器行为。
谷歌服务器和媒体
这一章中描述的技巧是从Internet Explorer中绕过XSS过滤器（稍后将详细介绍）。
默认情况下，Google服务器会规范化查询路径。例如，GET/test/./test2 HTTP/1.1请求将不由应用服务器处理，而是首先重定向到标准化路径，即test2（图4）。
图四。Google服务器的路径规范化
但是，似乎可以通过在路径中添加字符来“禁用”此行为。服务器显然结束了对中间路径的解释（将中间看作所谓的分隔符）。路径参数），您可以将任何字符串放在它后面。例如，对于GET/test/；/../test2 HTTP/1.1请求，服务器将不再通过重定向响应，而是通过404错误响应，这证明它只是试图在没有正常化的情况下对该路径执行查询（图5）。
图五。中间路径没有重定向
Google CSE中的XSS
最后让我们转到Google自定义搜索引擎中的右侧XSS。这是唯一一个我发现在没有加密的情况下编写主机头的地方（图6）
图六。未加密的主机头
Burp给代码上色的方式是错误的，事实上，脚本代码位于标记<textarea>和HTML注释之外，将由浏览器完成。
所以我准备了一个对应于以下重定向的页面：
HTTP/1.1协议
服务器：Apache/2.2.22（Debian）
位置：https://www.google.com%2a443%2fcse%2ftools%2fcreate'u在%3b%3c%2ftextarea%3e%3cscript%3ealert（1）%3c%2fscript%3e上
希望在下一个请求中发送主机头：w w w.google.com:443/cse/tools/create onthefly；</textarea><script>警报（1）</script>。事实上，这个标题是发送的，但IE很警惕（图7）
图七。IE XSS筛选器阻止脚本执行
所以我不得不使用一个我在前面提到的技巧。Black2Fan也描述了这个技巧。IE XSS过滤器将地址栏的内容与页面上的内容进行比较。如果他发现要执行的脚本在地址中，他将拒绝它作为对XSS攻击的尝试。然而，事实证明，通过使用每个直径的多个字符序列，这种比较很容易被愚弄。这是因为IE本身规范了它在地址栏中显示的路径。这意味着，如果要查找http://example.com/；<script>警报（1）</script>。/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../。。
最后，我创建了一个与标题对应的页面：
功率功率功率功率功率功率功率功率功率功率功率功率%2e%2f%2e%2e%2f%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e
（其中值解码到位置：https://www.google.com:443/cse/tools/create/onthefly；</textarea><svg/onload=alert（document.domain）>/../../../../../../../../../../../../../../../../../../../../
您可以在下面的视频中看到此脚本的结果：
日历
- 2015-01-27（01:12）发送给谷歌的错误消息，
- 2015-01-27（16:03）谷歌安全团队成员确认错误，
- 2015-02-25：确认错误已纠正，
- 2015-03-06：安全理事会出版物。
摘要
在本文中，我展示了w w.google.com域中的XSS，它已经使用Internet Explorer中众所周知的问题来操作主机头数年了。此外，我必须找到一种方法在Google服务器上使用它（通过端口号），并绕过XSS过滤器。
MichaelBentkowski，博客作者，Securitum的penter。