翻译作者:DM(信安之路前端安全小组成员)

原文地址:-xss-in-google-colaboratory.html

成员招募:

三个月以前,我写了一篇文章来介绍我在 Google Colaboratory 上发现的一个 XSS 漏洞,这篇文章是对前文的一些扩展,并且展示了我在同一个 web 应用中发现的另一个 XSS。所以我建议先看看上一篇文章再阅读本文。

我们先来简单回顾一下上篇文章中我们是如何找到 Google Calaboratory 中的那个 XSS 的:

1、首先我分析了一下 Google Calaboratory 这个应用中的 XSS 漏洞

2、然后我发现这个应用使用了一个 MathJax 库来渲染 LaTex 公式

3、最后我在 MathJax 中找到了一个 XSS,其本身就是对 LaTeX 公式中的\ unicode {}指令的滥用导致了这个XSS

从技术角度来看,这个问题不应该怪罪 MathJax 本身,而是出在一个默认被激活的插件 Assitive MathML 上。在 MathJax 的作者修复这个 bug 之前,谷歌只是通过禁用插件来摆脱 XSS。这种做法从根本上消除了 XSS 的问题,不愧是一个非常机智的方法,不是么?

这种做法确实可以从根本消除 XSS 问题,除非我有办法重新启用这个插件。

这一次,我又尝试在 Google Colaboratory 寻找其他 XSS 漏洞的时候,注意到了一个有趣的行为:当我按下右键单击 MarkDown 中生成的 LaTeX 公式时,我得到一个标准的 Colaboratory 弹出菜单。但是,当我右键单击目录时,我会得到一个 MathJax 菜单!见下图:

这就证明代码中有一部分代码可以去重新打开 Assistiv MathML 插件!

当我这样做时,我前一篇文章中提到的 XSS 方法,又生效了

$ \unicode {41 <img src = 1 onerror = alert(document.domain)>} $

找了一下,在 cookie 中找到了重新启用 Assistive MathML 的方法。注意到以下

cookie: mjx.menu = assistiveMML:true

由于 cookie 可以跨子域设置,所以这对我们寻找到XSS非常有利。四年前我在博客文章中写了另一个关于通过cookie 引发 XSS 的例子 ,所以这里直接给出攻击方案:

1、如果在 Google 其他任意的子域上存在一个我们能利用的 XSS,例如:some-random-domain.google.com

2、在该域中,我们设置了

cookie:document.cookie =“mjx.menu = assistiveMML:true; Domain = .google.com; Path = /”

3、现在,我们刚刚设置的名为mjx.menu的 cookie 会在每次请求 Google 子域时自动添加到请求中

我通过在 /etc/hosts 中定义  some-random-domain.google.com然后使用以下代码来模拟攻击:

<!doctype html>   <meta charset= utf-8><button onclick= exploit()style= font-size:48px>  设置cookie并重定向到Colaboratory!</button><SCRIPT>   function exploit() {       const COLAB_URL="";       document.cookie="mjx.menu = assistiveMML:true; Domain = .google.com; Path = /";       location=COLAB_URL;  }</script>以下是结果:

从这个 XSS 中我得到的最重要的结论是,在审计任何外部 JS 库时,必须特别注意其存储机制(如 cookie 或 localStorage)。对于 MathJax ,在加载库时会从 cookie 中读取配置去覆盖默认选项,这就给构造 XSS 带来了可乘之机。另一点就是 cookie 的作用域设置带来的安全问题。一个子域设置的 cookie 需要被另一个子域使用时,务必检查 cookie 中内容的安全性。