An Accidental SSRF Honeypot in Google Calendar
字数 1188 2025-08-26 22:11:45

Google日历中的SSRF漏洞研究分析

1. 背景介绍

Google日历提供了一个通过URL添加远程日历的功能，该功能允许Google服务器从远程日历获取事件并添加到用户日历中。这一机制本质上是通过Google服务器发起HTTP请求来获取外部日历数据，从而可能构成一个潜在的SSRF（Server-Side Request Forgery，服务器端请求伪造）攻击面。

2. 初步测试

2.1 第一次尝试

  • 测试方法：尝试访问外部URL和内部地址（如localhost）
  • 观察结果：
    • 访问外部URL时服务器报错（不可达或错误格式）
    • 访问内部地址得到相同错误
    • 未发现明显的SSRF迹象

2.2 自动化扫描

  • 使用工具：Fiddler组件和Burp Intruder
  • 扫描目标：localhost上的不同端口
  • 发现：
    • 某些端口（80、443、22）返回不同响应
    • 其他测试端口关闭
    • 对内网服务器（guts-remedy-linux-prod03.vm.corp.google.com）扫描确认22端口开放

3. 漏洞确认

基于扫描结果，研究者确认：

  1. 能够通过Google服务器发送内部HTTP GET请求
  2. 能够获取端口状态信息（开放/关闭）
  3. 确认存在"盲SSRF"漏洞（Blind SSRF）

4. 与Google团队的互动

4.1 报告过程

  • 报告提交后Google团队快速响应
  • 复现发现复杂性：
    • 自动化扫描速度受限（存在速率限制）
    • 但问题仍可复现
    • UI问题导致团队收到不同结果

4.2 验证测试

  • 创建全新Google日历账号重新测试
  • 结果与之前一致
  • Google团队确认问题并创建新bug

5. 最终结论

Google产品团队调查后发现：

  • 观察到的"开放端口"实际上是缓存机制异常导致
  • 问题与安全无关
  • 缓存问题已被修复（同样错误不再出现）

6. 技术要点总结

6.1 关键发现

  1. Google日历的URL导入功能可能成为SSRF攻击面
  2. 通过精心构造请求可探测内部网络端口状态
  3. 自动化工具在漏洞挖掘中的重要性
  4. 缓存机制可能产生误导性结果

6.2 方法论启示

  1. 不要因初步负面结果而放弃深入研究
  2. 自动化扫描可揭示手动测试难以发现的问题
  3. 与安全团队合作验证的重要性
  4. 表面看似安全漏洞的问题可能有其他解释

7. 防御建议

对于类似功能的开发者：

  1. 实施严格的URL验证和过滤
  2. 限制内部网络访问
  3. 监控异常的请求模式
  4. 确保缓存机制正常工作
  5. 考虑实施速率限制

8. 学习要点

  1. SSRF漏洞可能存在于各种意想不到的功能中
  2. 盲SSRF的识别和利用技术
  3. 安全研究中的坚持和细致观察的重要性
  4. 厂商响应和安全团队协作的最佳实践

9. 参考资料

原始文章链接：https://www.komodosec.com/post/an-accidental-ssrf-honeypot-in-google-calendar

Google日历中的SSRF漏洞研究分析 1. 背景介绍 Google日历提供了一个通过URL添加远程日历的功能，该功能允许Google服务器从远程日历获取事件并添加到用户日历中。这一机制本质上是通过Google服务器发起HTTP请求来获取外部日历数据，从而可能构成一个潜在的SSRF（Server-Side Request Forgery，服务器端请求伪造）攻击面。 2. 初步测试 2.1 第一次尝试 测试方法：尝试访问外部URL和内部地址（如localhost） 观察结果： 访问外部URL时服务器报错（不可达或错误格式） 访问内部地址得到相同错误 未发现明显的SSRF迹象 2.2 自动化扫描 使用工具：Fiddler组件和Burp Intruder 扫描目标：localhost上的不同端口 发现： 某些端口（80、443、22）返回不同响应 其他测试端口关闭 对内网服务器（guts-remedy-linux-prod03.vm.corp.google.com）扫描确认22端口开放 3. 漏洞确认 基于扫描结果，研究者确认： 能够通过Google服务器发送内部HTTP GET请求 能够获取端口状态信息（开放/关闭） 确认存在"盲SSRF"漏洞（Blind SSRF） 4. 与Google团队的互动 4.1 报告过程 报告提交后Google团队快速响应 复现发现复杂性： 自动化扫描速度受限（存在速率限制） 但问题仍可复现 UI问题导致团队收到不同结果 4.2 验证测试 创建全新Google日历账号重新测试 结果与之前一致 Google团队确认问题并创建新bug 5. 最终结论 Google产品团队调查后发现： 观察到的"开放端口"实际上是缓存机制异常导致 问题与安全无关 缓存问题已被修复（同样错误不再出现） 6. 技术要点总结 6.1 关键发现 Google日历的URL导入功能可能成为SSRF攻击面 通过精心构造请求可探测内部网络端口状态 自动化工具在漏洞挖掘中的重要性 缓存机制可能产生误导性结果 6.2 方法论启示 不要因初步负面结果而放弃深入研究 自动化扫描可揭示手动测试难以发现的问题 与安全团队合作验证的重要性 表面看似安全漏洞的问题可能有其他解释 7. 防御建议 对于类似功能的开发者： 实施严格的URL验证和过滤 限制内部网络访问 监控异常的请求模式 确保缓存机制正常工作 考虑实施速率限制 8. 学习要点 SSRF漏洞可能存在于各种意想不到的功能中 盲SSRF的识别和利用技术 安全研究中的坚持和细致观察的重要性 厂商响应和安全团队协作的最佳实践 9. 参考资料 原始文章链接：https://www.komodosec.com/post/an-accidental-ssrf-honeypot-in-google-calendar