在这篇文章里,越南籍作者通过发现了谷歌翻译服务(Google Translator)越翻英界面中存在的跨站漏洞(XSS),最后经测试验证,获得了谷歌官方奖励的$3133.70,我们一起来看看。
河内,凌晨2点的冬天,大家都进入了梦乡,我还在投入地加班工作,结束时已经是凌晨02:45。临睡前准备放松一下,打算找部电影看看,但记不起电影的准确英文名了,于是打开了谷歌翻译网站translate.google.com,在其中输入了越南语,想把它转换成英语,之后,我突然发现了一些端倪,于是尝试在其中输入了其它验证性Payload,如下图红色部分所示:
我马上按F12进入的Chrome开发者模式进行检查,我发现我输入的Payload已经被成功执行了,如下:
这说明……,谷歌针对HTML标签功能未做完善的过滤和编码规则,所以导致了我能在这里执行XSS。于是我尝试看看谷歌的其它语言翻译界面是否存在该漏洞,但是好像不行,它们都实施了过滤编码,只有这里的越南语(Primary language)翻译为英语(Language after translation)界面存在该漏洞。
为了更好地验证该XSS漏洞,我构造了HTML代码试图让translate.google.com反弹出当前域名和用户Cookie信息,这里比较难的是对字符长度的控制,最后的HTML Payload如下:
<iframe onload=”javascript:prompt(document.domain, document.cookie)” id=”xss” role=”xss”>hello xss
translate.google.com反弹出的提示窗如下:
结合上述HTML Payload,最终在浏览器端可执行的URL XSS Payload如下:
https://translate.google.com/?hl=en#view=home&op=translate&sl=vi&tl=en&text=%3Ciframe%20onload=%22javascript:alert(document.domain)%22%20id=%22xss%22%20role=%22xss%22%3Ehello%20xss
运行该URL XSS Payload后,浏览器中其请求的参数为:
& sl = en => Primary language
& tl = en => Language after translation
& text => Paragraphs
所以,常规来说,只要我对其中的XSS Payload做一些相应的编码转换,然后把上述URL发送给受害者,XSS的执行是没问题的。但是,当我把该漏洞提交给谷歌安全团队之后,却被告知这是一个无效漏洞,因为他们认为其中的域名隶属于“沙箱安全域名”(sandbox domains)范畴,所以该漏洞直接被归为了“不需要修复”(Won’t Fix)的类别。
当时我非常沮丧,于是就去查了查谷歌所谓的sandbox domains范围,如下:
这……,上面根本没有translate.google.com啊!谷歌设置所谓的sandbox domains目的在于,针对提供给用户的前端服务中,避免用户植入木马、病毒等恶意程序从而影响到其它谷歌服务,因此实行沙箱隔离的一类域名。这里的translate.google.com就不在谷歌所述的sandbox domain之内,他们绝对是搞错了。
之后,我又向谷歌发送了相关说明,他们接收并提高了该漏洞的威胁级别,还给了我奖励。最后我要感谢漏洞众测社区的网友,他们中的一些人帮我一起验证谷歌搞错了,并给了我鼓励。
14/11/201914:05 — 漏洞初报
14/11/2019 20:29 — 谷歌回应该漏洞归为“不需要修复” 类别
14/11/2019 21:29 — 我提供了更多参考信息
11/15/2019 00:36 — 我向谷歌说明了translate.google.com不在他们所说的沙箱域名之内
21/11/2019 23:23 — 我又向谷歌发送了一个PoC验证视频
11/22/2019 00:12 — 谷歌接收了该漏洞并提高了漏洞级别
11/28, 2019 01:20 — 谷歌奖励了我 $3133.70
23/12/2019 03:47 — 谷歌修复了该漏洞
*参考来源:medium,clouds 编译整理,转载请注明来自 FreeBuf.COM