本文是翻译文章，原文链接为：https://www.komodosec.com/post/an-accidental-ssrf-honeypot-in-google-calendar

这是一个我和Google工程师都误以为是Google日历中的SSRF漏洞的故事，最后实际上是因为一些缓存机制的缘故。虽然结果不太好，但是我和Google安全团队的交流很好。

从URL导入日历

Google日历有很多不错的功能，其中有一个正如它名字一样，可以通过URL添加一个远程的日历。

Google服务器可以从远程日历上把事件添加到你自己的日历中。或者也可以说是我们使用了Google服务器的HTTP请求。所以访问外部URL是Google服务器的内部操作。但是我们说不定可以通过这个方法去访问一些内网资源（例如localhost）？或者说我们可以在这里发现一个SSRF漏洞。

第一次尝试——貌似安全

第一次测试并没有得到有趣的记过，因为当我们尝试去访问外部URL时，服务器报错了（不可达或错误格式等错误），当我们输入一个内部地址我们得到了同样的错误。ADDRESS:PORT既没有给我们一个真实的端点也没有给一个假的端点。

注意到这里curl就是POST参数（可能是calendar url的缩写），而不是一个curl工具。

犹豫不决，那就扫描！

只是为了确信我没有错过什么（可能没有127.0.0.1:443这个端点）。我决定针对localhost上的端口做一个快速的自动化扫描（使用Fiddler的组件发送序列包）。令我惊讶的是，当我使用自动化脚本的时候我发现一些不同的结果。突然，“不存在的”地址端口出现在了结果里。

这个结果告诉我们有些端口可能开着，有些端口可能关着。我调整了我的代理工具然后再Burp Intruder里跑扫描（payload是端口，不同的结果长度意味着端口可能开着或关着）。这个结果和我想要的一样。

在图中可以看到很明显，80,443,22都开着（从内部服务器访问），其他的测试端口都关着。我快速对内网服务器（guts-remedy-linux-prod03.vm.corp.google.com）进行了一个再次扫描并如我所预料地一样发现22端口开着。

通过这个点我可以确信：

1. 我通过Google服务器发送了内部的HTTP的GET请求，并且我可以做一个自动化脚本；
2. 我可以接收到一些有用的信息（端口是否开着）。

或者换个说法，我在Google日历中发现了一个“盲SSRF”，是时候报告它。

Google工程师复现发现一个bug

我和Google的团队的交流非常迅速。在验证这些问题时他们发现有点复杂，生成结果的时候所做的自动化扫描的时候不能太快（有限制因素在其中）。但是尽管如此，问题还是被复现了。但是一个新的问题被发现了。

所以Google的团队可以复现这个问题，但是他们因为UI的问题导致收到了不一样的结果。为了验证Google的理论，我创建了一个新的没有使用痕迹的Google日历账号并再次测试（没有UI干扰）。我发现结果和之前的一样。

这个点上Google的团队和我认为的一样并且开了一个新的bug。

产品团队发现问题和安全无关

做完这些研究后，Google的产品团队发现这个问题和安全无关。我所找到的打开的端口实际上是因为一个缓存机制没有按预想一样工作导致的。

报告被关闭了我收到了回复。

最后的思考

我非常尊重Google的团队，因为他们没有放弃这个，直到他们整理出来（缓存问题BTW已修复 - 同样的错误不再返回）。 不能说我没有失望地发现在旅程结束时，我的SSRF只不过是一个幽灵，但我当然很享受骑行。 我认为对我来说最重要的一点就是不要因最初失败的结果而气馁，因为有时候更深层次的潜水会带你进入复杂而迷人的道路。 这次它导致了一个行为不端的缓存，也许下次会导致一个RCE :)