挖洞经验 | 绕过谷歌XSS修复措施收获翻倍赏金($10000)
字数 1274 2025-08-15 21:31:58

绕过谷歌XSS修复措施的高级技巧与实战分析

漏洞背景与发现过程

谷歌地图KML导出功能中的XSS漏洞

谷歌地图(Google Maps)的"export as KML"功能允许用户创建自定义地图并导出为KML格式(类似XML)。当用户创建包含恶意脚本的地图名称时，如blabla<script>alert(1)</script>，服务端响应会将XSS Payload包裹在CDATA标签中：

<![CDATA[blabla<script>alert(1)</script>]]>

这种处理方式本应防止XSS攻击，因为CDATA部分的内容不会被解析为标记。

第一次XSS漏洞利用

绕过CDATA防护的技术细节

通过研究发现，在XSS Payload开头添加]]>可以闭合CDATA标签：

  1. 创建自定义地图
  2. 在地图名称处使用]]>配合SVG格式构造Payload
  3. 示例Payload结构： 
    ]]><svg/onload=alert(1)>

这种技术成功绕过了CDATA防护，使SVG中的脚本得以执行。该漏洞被谷歌确认并奖励$5000。

谷歌的修复措施与绕过方法

初始修复方案分析

谷歌采取的修复措施是双重CDATA包裹：

  • 原始输入：<script> → 变形为：<![CDATA[<script>]]>
  • 原始输入：]]><script> → 变形为：<![CDATA[<![CDATA[<script>]]>]]>

第二次绕过技术

发现谷歌只是简单添加了另一层CDATA标签，因此构造特殊Payload：

]]>]]><svg/onload=alert(1)>

这种构造会：

  1. 第一个]]>闭合第一个CDATA
  2. 第二个]]>闭合第二个CDATA
  3. 剩余的<svg/onload=alert(1)>作为有效标记被解析

该绕过方法在收到修复通知后10分钟内被发现，再次获得$5000奖励。

关键经验总结

  1. 修复验证的重要性：即使厂商声称漏洞已修复，也应进行复测
  2. 防御机制的局限性：简单的过滤或转义往往容易被绕过
  3. 漏洞的持续性：同一漏洞点可能存在多种利用方式
  4. 赏金翻倍机会：绕过修复措施通常能获得额外奖励

漏洞时间线

日期 事件
2019-04-23 上报第一个XSS漏洞
2019-04-27 谷歌确认漏洞有效
2019-05-07 获得$5000奖励
2019-06-07 收到修复通知并绕过修复
2019-06-07 谷歌确认绕过有效
2019-06-18 再次获得$5000奖励

防御建议

对于开发人员：

  1. 避免简单的字符串过滤或转义
  2. 实施多层次防御机制
  3. 对用户输入进行严格的白名单验证
  4. 考虑使用专门的XSS防护库

对于安全研究人员：

  1. 养成对已修复漏洞进行复测的习惯
  2. 关注防御机制的具体实现方式
  3. 尝试多种上下文和编码方式的Payload
  4. 记录并分析厂商的修复方案

扩展思考

这种类型的漏洞利用展示了：

  1. XML处理中的安全边界问题
  2. CDATA标签的特殊解析行为
  3. 多层嵌套结构的逃逸技术
  4. 前后端解析不一致导致的安全问题

通过深入研究这类漏洞，可以更好地理解现代Web应用的安全防护机制及其局限性。

绕过谷歌XSS修复措施的高级技巧与实战分析 漏洞背景与发现过程 谷歌地图KML导出功能中的XSS漏洞 谷歌地图(Google Maps)的"export as KML"功能允许用户创建自定义地图并导出为KML格式(类似XML)。当用户创建包含恶意脚本的地图名称时，如 blabla<script>alert(1)</script> ，服务端响应会将XSS Payload包裹在CDATA标签中： 这种处理方式本应防止XSS攻击，因为CDATA部分的内容不会被解析为标记。 第一次XSS漏洞利用 绕过CDATA防护的技术细节 通过研究发现，在XSS Payload开头添加 ]]> 可以闭合CDATA标签： 创建自定义地图 在地图名称处使用 ]]> 配合SVG格式构造Payload 示例Payload结构： 这种技术成功绕过了CDATA防护，使SVG中的脚本得以执行。该漏洞被谷歌确认并奖励$5000。 谷歌的修复措施与绕过方法 初始修复方案分析 谷歌采取的修复措施是双重CDATA包裹： 原始输入： <script> → 变形为： <![CDATA[<script>]]> 原始输入： ]]><script> → 变形为： <![CDATA[<![CDATA[<script>]]>]]> 第二次绕过技术 发现谷歌只是简单添加了另一层CDATA标签，因此构造特殊Payload： 这种构造会： 第一个 ]]> 闭合第一个CDATA 第二个 ]]> 闭合第二个CDATA 剩余的 <svg/onload=alert(1)> 作为有效标记被解析 该绕过方法在收到修复通知后10分钟内被发现，再次获得$5000奖励。 关键经验总结 修复验证的重要性 ：即使厂商声称漏洞已修复，也应进行复测 防御机制的局限性 ：简单的过滤或转义往往容易被绕过 漏洞的持续性 ：同一漏洞点可能存在多种利用方式 赏金翻倍机会 ：绕过修复措施通常能获得额外奖励 漏洞时间线 | 日期 | 事件 | |------|------| | 2019-04-23 | 上报第一个XSS漏洞 | | 2019-04-27 | 谷歌确认漏洞有效 | | 2019-05-07 | 获得$5000奖励 | | 2019-06-07 | 收到修复通知并绕过修复 | | 2019-06-07 | 谷歌确认绕过有效 | | 2019-06-18 | 再次获得$5000奖励 | 防御建议 对于开发人员： 避免简单的字符串过滤或转义 实施多层次防御机制 对用户输入进行严格的白名单验证 考虑使用专门的XSS防护库 对于安全研究人员： 养成对已修复漏洞进行复测的习惯 关注防御机制的具体实现方式 尝试多种上下文和编码方式的Payload 记录并分析厂商的修复方案 扩展思考 这种类型的漏洞利用展示了： XML处理中的安全边界问题 CDATA标签的特殊解析行为 多层嵌套结构的逃逸技术 前后端解析不一致导致的安全问题 通过深入研究这类漏洞，可以更好地理解现代Web应用的安全防护机制及其局限性。