新闻链接：http://www.freebuf.com/vuls/97463.html
新闻时间：2016-03-02
新闻正文:

Google Work Connect（GWC）是一个由系统、应用管理员和合作伙伴组成的社区系统，也在谷歌的漏洞悬赏范围内。不久之前，我在GWC社区系统发现了反射型、存储型、DOM型的XSS。 
存储型XSS

在GWC社区系统中，不同应用的管理员间可以互相分享他们自己的观点。这个社区系统允许用户创建文档、文章、讨论/消息（还有其他的比如标记问题、标签）等，文章包含一个标题和一个正文，标题是我们最感兴趣的点，但是该系统会把<编码成HTML实体<



如上图，<被编码成了HTML实体，所以在这个点上我们没办法利用了，不过通过Google Drive我们也能做同样的事情。在Google Drive上，有个“上传文件到Google Drive”的功能，上传的文件名会成为文章的标题。



如上图，我在Google Drive上上传了“xxxxxxxx’yyyyy</img>.PNG，然后该文件名被放到了script标签的title中，但是“ 和 </并没有编码或者过滤，所以可以构造xss。



如上图，在Google Drive中上传一个名为 </script><script>confirm(document.domain)</script>的文件，然后该文件名被嵌套进了GWC社区系统中，该xss为存储型xss，任何登录的用户看到该文章，都会触发该xss。

这个存储型xss形成的成因是GWC社区系统在引入其他应用的数据（Google Drive）时，没有对该数据进行控制/编码/过滤而直接使用，但是在他们各自的应用中，对于用户提交的数据是处理的很好的。
反射型XSS

如果你能触发错误（比如在Google Drive中文件没上传好），GWC社区系统就会在GET请求”googleDriveError”参数中抛出一个错误信息，这个参数能够构造反射型xss。还有如果你能构造一个认证错误，该错误信息也会被放置在GET请求的“error”参数中。如下图所示，GET请求的 “googleDriveError”参数中包含了我们无害的测试字符“xxxxxxxx’yyyyy</img。



在上图中，你还能看到<并没有被编码成HTML实体。



如上图，通过GET请求的“googleDriveError”参数来构造xss。



如上图，通过GET请求的“error”参数来构造xss。
DOM型XSS

罪魁祸首是window.location.hash.substring(1)，但是这边有一个限制：只有当用户将文章标记为“Mark as Helpful”时才能触发该xss。有问题的JavaScript代码如下：

... {if(window.location.hash){c.scrollTo("a[name='"+window.location.hash.substring(1)+"']")} ...



如上图，该文章没有被标记为“Mark as Helpful”，所以没有触发该xss。


如上图，文章被标记为“Mark as Helpful”，所以触发了该XSS。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课