译：一个有趣的价值3133.7美金的Google漏洞

原文链接：http://www.sec-down.com/wordpress/?p=809

在Google上进行安全研究时。 我决定专注于“Cloud.google.com”域名，因为该域名听起来很有趣，而且有很多功能。

而在我的测试期间，在Burp Proxy中看到以下这个非常有趣的请求：

https://cloudusersettings-pa.clients6.google.com/batch?%24ct=multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985            

注意：该页面的原始响应是JSON格式中的“未找到”，但这并不重要。

关于这个HTTP请求，我立刻注意到了两件事。 首先，POST请求中包含一个GET请求，而且还有请求头。 其次是能够通过POST请求的URL中的值来控制内容类型。 最后，我注意到在POST请求正文中发送了一个KEY。

我的猜想：

“cloudusersettings-pa.clients6.google.com”服务器正在通过POST请求正文将GET请求转发给中间服务器（反向代理/负载均衡器），中间服务器将以某种方式解析它并处理它或将其传递给第三个业务服务器。 中间服务器不关心原始POST请求的请求头，而只关心在POST请求主体中发送的GET请求请求头。

那么，可得出以下结论：

1）我能够控制中间服务器将处理的HTTP请求头;

2）可以通过以下标记为红色的值来控制响应类型：

https://cloudusersettings-pa.clients6.google.com/batch?%24ct=multipart％2Fmixed％3B％20boundary％3Dbatch392541909285510985

3）请求中有密钥和被授权的请求头值。

经过我的测试，第2个和第3个测试没有任何异常。从另一方面来说，这些内容不会经过后端验证，让我们记住这一点。

现在我们来到有趣的部分，即改变HTTP请求头本身。 我的方法是针对POST正文中的GET请求执行以下测试用例：

1）围绕HOST这个请求头进行重放。 就是将主机头设置为dev，localhost，portal等。 借此，网络服务器也许会被欺骗从而披露本地配置的虚拟主机名。导致一个允许外网访问内部环境的漏洞。（无效果）

2）通过以下请求头伪造我的IP地址。 尝试诱导接收请求的后端服务器以不同的方式处理它。（无效果）

X-Forwarded-For：127.0.0.1
X-Client-IP：127.0.0.1
Client IP：127.0.0.1 

3）强制后端服务器接受一些错误字符。例如发送AAAAA的大量输入，将HTTP协议版本1.1更改为其他内容，添加一些随机标头或操纵内容类型等等来尝试（无效果）

4）在user-Agent值中盲注XSS以及SQLI，期待payload可能会在某个时刻生效！（无效果）

5）还试图操纵Origin请求头，希望找到CORS实现中的错误配置，但没有效果。

排除以上选择之后，我想到了为什么我不直接用后端服务器所能理解的方式“交谈”？！ Web服务器的语言基本上是请求头！ 它看到请求头，它解析它，然后处理它，简单！

允许您与Web服务器“对话”的一个有趣的请求头是“ X-HTTP-Method-Override ”。 这个标题允许一些神奇的东西 例如，您可以将GET请求发送到服务器，但服务器会将其视为PUT，POST，DELETE或您声明的任何方法！ 是的，虽然它看起来是一个GET请求。

一个例子如下：

GET /test.php HTTP / 1.1

Host：google.com

User-Agent：Mozilla / 5.0（X11; Linux x86_64; rv：45.0）Gecko / 20100101 Firefox / 45.0

Accept：text / html，application / xhtml + xm l，application / xm l; q = 0.9，* / *; q = 0.8

Accept-Language：en-US，en; q = 0.5

X-HTTP-Method-Override ： PUT

Accept-Encoding：gzip，deflate

Connection：close

当Web服务器收到上述GET请求并解析它时，它会在那里找到XHMO标头并说

“哦！ 这是一个GET请求，但用户希望我将其视为PUT” 然后将其视为PUT请求而不是GET请求。

而这种请求头存在的原因是，一些中间服务器（例如反向代理，负载平衡器，WAF）所支持的HTTP方法受到限（即仅支持GET和POST）。 但是，开发人员可能仍希望发送“PATCH，DELETE，PUT”方法。 这时候就是XHMO发挥作用的时候了。

哦，我提到我曾经通过HTTP PUT方法触发RCE并且启用了webdav，而F5的WAF仅仅只是看着这些流量吗？

我的burp repeater： -> 嘿Web服务器，我希望你通过PUT方法创建一个文件 - > F5说：你必须首先通过我，而我只支持GET or POST！ -> 失败

我的burp repeater： -> 嘿F5，我知道后端服务器支持PUT，所以这是你的GET请求，XHMO设置为PUT。 请将它传递给后端服务器 -> F5说：确定，看起来合法！ ->后端网络服务器：是的，接到一个PUT请求处理。 你的文件将PUT而创建的，我理解你的请求。 -> bingo！

基于以上说明，我使用HTTP方法PUT将XHMO标头添加到请求中，希望在后端网络服务器上启用webdav，以便我可以以这种方式获得RCE。是的，它并没有生效，但是！！！！！

由于中间网络服务器无法理解该如何处理该请求头！ 所以它决定向用户展示一个非常详细的错误消息说明，这些消息包括：

HTTPOnly和安全cookie！
中间服务器和后端服务器之间连接的所有通信详细信息。 包括SSL hello消息，IP，端口等;
还有被授权请求头和一些更有趣的消息。 

注意：截图的质量差是故意的。

还记得当我上文说的说请求中没有任何内容会被真正验证时吗？ 基于此，我创建了一个CSRF POC，可以被其他Google用户触发相同，返回类似的错误响应，因此，我可以使用反射的XSS窃取这些信息！

从理论上讲，开启HTTPOnly可以很好地抵御XSS攻击。 但是，利用此漏洞，还是可以会窃取点击了恶意链接的Google用户的基于HTTPOnly保护下的 Cookie。

而这只发生在添加了XHMO标头时，页面所返回的错误信息响应中。

我已向Google报告此漏洞，该团队已将优先级设为P1。 他们反应迅速，专业处理漏洞。 稍后，收到以下来自Google的电子邮件：