在对Google的安全研究中，由于其云服务平台“cloud.google.com” 具备多种功能，感觉有点意思，所以某天我决定来深入测试一下它。
测试开始
测试一开始，我就在Burp Proxy中发现了以下这个有趣的链接请求：
该请求的原始响应消息是一个JSON格式的404 NOT FOUND。但这里的请求内容引起了我的注意，首先是，和请求的头消息一起，GET请求也被包含在了这个POST请求中；另外是，可以通过主请求URL中的值来对content-type进行控制；还有，可以注意到，在POST请求的发送内容中，包含了一个key值。
思路考虑
我的想法是：
该请求执行过程，服务器“cloudusersettings-pa.clients6.google.com” 通过POST请求内容，把GET请求中继转发给了一个中间服务器，这个中间服务器可以是一个反向代理或负载均衡器，然后，这个中间服务器会以某种方式来解析这个GET请求，之后再对其进行处理或将其转发给另一个服务器。中间服务器并不关心原始POST请求的header头信息，它只解析包含在POST请求中的GET请求header头信息。
总结起来可以概括为以下几点：
1.我可以控制中间服务器将要处理的header头信息；
2.可以通过以下链接中的multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985来控制响应内容类型：
3.在请求内容中包含了一个key和授权头值（authorization header value）
各种测试
为了实现我的这种猜测，我进行了一系列的测试验证，上述第2和第3种情况是行不通的，但我发现其中的消息是无验证机制的（validated），只有第1种情况是可以实现。为了实现对POST请求内容中的GET请求进行测试，我大概实验的方法如下：
1.在HOST主机头中尝试做一些虚拟主机名枚举，如dev、localhost、portal等都来一遍，借希望从一些曝露的web