每位Web挖洞者可能都有这样的感受，当收到厂商关于你上报漏洞已被及时修复（fixed）的邮件告知后，我们多少会觉得：好吧，修复就好，听你们的。但有些时候，这种漏洞已修复状态并不代表该漏洞“已成定局”或“不可挽回”了。这不，本文作者就分享了他“发现谷歌XSS漏洞，然后上报谷歌修复(Fix)，接着再次绕过(Bypass)”，收获$10000奖励的感人事例。我们一起来看看。
去年底，我奔波各地忙于找工作，闲暇在酒店的某晚，突然电子邮箱中收到了谷歌发来的一封主题为“fixed”的邮件，内容是告知我之前上报的谷歌地图（Google Maps）XSS漏洞已被修复的消息。
本来吧，通常认为就是：谷歌这种大厂，修复个XSS漏洞当然不在话下了，它说修复就修复呗。然而在当时的无聊时刻，我竟然冒出了尝试复测的想法。果然十分钟不到，我就手动绕过了谷歌的修复防护措施，再次证明了漏洞存在性，并实现了漏洞赏金翻倍的愿望。
谷歌地图（Google Maps）的'export as KML'功能
谷歌地图（Google Maps）里有一项功能就是创建自己的地图，通过该功能可以创建自定义地图，并可以把它导出为几种不同格式，其中一种格式即为类似XML的KML。比如，我们创建一个名为 ‘blabla<script>alert(1)</script>’ 的自定义地图，把它导出为KML后，谷歌服务端的响应为：
有点意思，可以看到其是一个包含了KML标记的XML响应消息体，但可能由于我们定义的地图名称有尖括号，因此，其中的XSS Payload被用CDATA的文本标签套住了，也就是说，我们的XSS Payload不能得到有效解析，那能否想办法闭合这个CDATA标签呢？
第一个XSS漏洞: 转义CDATA标记成为SVG Payload
之后，我发现只需添加一些特殊字符就能闭合掉上述的CDATA标签，具体来说就是在XSS Payload开头添加‘]]>’字符，步骤就是：先创建自定义地图，接着在地图名称处用‘]]>’字符配合svg格式，添加任意XML内容成为SVG XSS Payload，实现绕过CDATA，下面是我发给谷歌安全团队的详细POC步骤（其中第3步少了一个'>'，在后续邮件中我已做了说明）：
可惜的是，我未对这第一个成功的XSS漏洞做截图，但这确实是一个有效的XSS漏洞。上报不久之后，我就收到谷歌的及时回复和5000$的奖励。
第二个XSS漏洞: 转义CDATA标签绕过谷歌修复措施
如上所述，回到文章开头我身处酒店的时候，收到了谷歌对我上报的XSS漏洞已修复的邮件告知：
复测想法油然而生后，我继续来到谷歌地图（Google maps）主页，继续用之前的自定义地图套路测试，但在我输入与之前同样的XSS Payload后，我发现谷歌的修复措施就是简单地添加了另一个CDATA标签。比如：
'<script>' 会被谷歌变形为 '<![CDATA[<script>]]>' (有点象最初的样子)
']]><script>' 会被谷歌变形为'<![CDATA[<![CDATA[<script>]]>]]>'
从上面第二个变形措施可以看到，谷歌这种做法成了两个CDATA开始标签，那好吧，我再添加两个CDATA结束标签试试，这一试，可不得了，直接就绕过了成功触发了XSS Payload！我赶紧发邮件向谷歌上报：
从收到修复告知邮件到上报修复绕过问题，前后不到十分钟。上报之后，我都有些自我怀疑的感觉。不过两小时后，我收到谷歌安全团队需要内部分析确认邮件，我才放心了：
几天之后，谷歌告知我第二个XSS漏洞有效且继续奖励了我$5000。
经验总结
其实也就在几个星期前，我对之前我上报且已被修复的谷歌Gsuite SMTP注入漏洞进行了复测，同样发现能绕过修复措施成功复现，并也实现了赏金翻倍。所以经历了这两次绕过谷歌漏洞修复措施的事例后，在后续的漏洞测试中，我总习惯了对已修复漏洞的继续复测，即使是一些简单漏洞，我也不放过。我也鼓励大家这么做，因为一不小心可能赏金就会翻倍。
漏洞上报和处理进程
04/23/2019 向谷歌上报第一个XSS漏洞
04/27/2019 谷歌确认"好洞"
05/07/2019 谷歌奖励$5000
06/07/2019 谷歌告知我漏洞已修复
06/07/2019 我绕过谷歌漏洞修复措施继续实现第二个XSS漏洞
06/07/2019 谷歌确认绕过有效
06/18/2019 谷歌再次奖励我$5000
参考来源：ehpus