三個月以前，我寫了一篇文章來介紹我在 Google Colaboratory 上發現的一個 XSS 漏洞，這篇文章是對前文的一些擴展，並且展示了我在同一個 web 應用中發現的另一個 XSS。所以我建議先看看上一篇文章再閱讀本文。
我是如何找到 Google Colaboratory 中的一個 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）>} $
好了，現在的問題是，我們是否有可能爲另一個用戶製造 XSS 漏洞？這還需解決另一個問題：MathJax 在哪裏存儲有關重新啓用 Assistive MathML 的信息？
找了一下，在 cookie 中找到了重新啓用 Assistive MathML 的方法。注意到以下
cookie：
mjx.menu = assistiveMML:true
由於 cookie 可以跨子域設置，所以這對我們尋找到XSS非常有利。四年前我在博客文章中寫了另一個關於通過cookie 引發 XSS 的例子 gmail和google的兩個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="https://colab.research.google.com/notebooks/welcome.ipynb";
document.cookie="mjx.menu = assistiveMML:true; Domain = .google.com; Path = /";
location=COLAB_URL;
}
</script>以下是結果：
從這個 XSS 中我得到的最重要的結論是，在審計任何外部 JS 庫時，必須特別注意其存儲機制（如 cookie 或 localStorage）。對於 MathJax ，在加載庫時會從 cookie 中讀取配置去覆蓋默認選項，這就給構造 XSS 帶來了可乘之機。另一點就是 cookie 的作用域設置帶來的安全問題。一個子域設置的 cookie 需要被另一個子域使用時，務必檢查 cookie 中內容的安全性。