翻譯作者：DM（信安之路前端安全小組成員）
原文位址：https://blog.bentkowski.info/2014/06/gmail-and-google-tale-of-two-xss-es.html
在這篇文章中，我會展示一下我在 Gmail 和 Google+ 中找到的兩個 XSS 漏洞。特别是我會解釋兩個問題：
- 為什麼我需要第二個平台去注入第一個平台；
- cookie 中的作用域的正确設定有多重要。
Gmail
Gmail 是我們最常用的的 google 服務之一，有很多不同的版本，包括基本 HTML 版本和移動版舊版。這次我要介紹的 XSS 漏洞發生在上面的兩個版本中。這些版本中的功能比較簡單，隻能完成最基礎的功能，隻有基本的檢視和發送郵件，但是最重要的一點是，我們可以設定标簽。
舉個例子，我們嘗試設定一個
<test>
标簽。
操作完成後，Gmail 會在通知中告知已對會話進行了标記。
當檢視 http 會話時，我發現通知的内容實際上被放在 cookie 裡。
cookie 裡的 html 實體
<
和
>
吸引了我的注意力，接着我們很自然地想到這裡是否能夠插入自定義标簽,例如
<img src=1 onerror=alert(1)>
然而這個 payload 沒起作用，伺服器報了 500 的錯誤。估計是 ">" 導緻了這個錯誤。因為右尖括号在 cookie 裡還有其他的用途。可能是 cookie 被 ">" 拆分，并且當有一個超出預期的字元傳入時，伺服器端會發生一些錯誤，是以我們需要再修改下 payload，去掉了右尖括号：
這次成功了，
alert
生效了，我在
mail.google.com
上找到了一個 xss 漏洞。
但現在仍然存在一個主要的問題。為了能夠利用這個漏洞，我需要能夠在受害者的浏覽器中去設定任意 cookie。這通常是不可能的，需要另一個滿足下面條件之一漏洞：
1、http 響應分割
2、無限制的設定 cookie：
https://miki.it/blog/2013/9/15/xsrf-cookie-setting-google/
3、另一個 xss 漏洞
前倆個條件非常難以滿足，是以我們隻關注第三個。還記得
Set-cookie
包含那些屬性嗎？
其中之一便是
domain
。是以當你發送一個消息頭時:
Set-Cookie: Test= test;
Domain= .google.com
...... 複制
你建立了一個 cookie, 而這個 cookie 會被發送到 Google.com 的任何子域。是以，我需要在任意其他 Google 子域上找到另一個 xss 漏洞，并使用它去設定一個 cookie 去注入 Gmail。Google 有大量的服務，是以這應該不難;)
Google+
我十分幸運地在 Google+ 上找到了另一個 xss 漏洞。就像在 Gmail 中一樣，這個漏洞存在于移動端而不是主版本。
這一次，我發現在上傳照片時，很容易受到攻擊。我注意到在上傳請求中有兩個很明顯的 base64 的 http 參數:
puSuccessResponse
和
puFailureResponse
。
解碼後：
解碼後的結果包含了上傳結束後的伺服器響應的 html 代碼。
puSuccessResponse
會在一切正常時運作，而
puFailureResponse
則是在失敗時運作。更有趣的是這個請求包含
CSRF token
，當
token
不正确時，伺服器會報 500 錯誤，但是
puFailureResponse
仍然會被應用！
做一個簡單的測試，讓我們用
alert(1)
來檢查一下：
現在我們将操作組合起來。
代碼如下:
<html>
<body>
<form action="https://plus.google.com/_/upload/app/basic/photos?cbp=&cid=5&soc-app=115&soc-platform=1"method="POST"enctype="multipart/form-data">
<input type="hidden"name="puSuccessResponse"value="aGVq"/>
<input type="hidden"name="puFailureResponse"value="PHNjcmlwdD4KYWxlcnQoIkR1ZGUsIHlvdSdyZSBYU1MtZWQgb24gIitkb2N1bWVudC5kb21haW4pOwpkb2N1bWVudC5jb29raWU9IkdNQUlMX05PVEk9dGwxPjxpbWcrc3JjJTNkMStvbmVycm9yJTNkJTIyYWxlcnQoJ0FuZCtub3crb24rJyUyYmRvY3VtZW50LmRvbWFpbiklMjIreDsgIERvbWFpbj0uZ29vZ2xlLmNvbTsgUGF0aD0vIjsKZG9jdW1lbnQubG9jYXRpb24gPSAiaHR0cHM6Ly9tYWlsLmdvb2dsZS5jb20vbWFpbC94LyI7ICAgCjwvc2NyaXB0PiAg"/>
<input type="submit"value="Double XSS!"/>
</form>
</body>
</html> 複制
puSuccessResponse
被解碼為:
<script>
alert("Dude, you're XSS-ed on "+document.domain);
document.cookie="GMAIL_NOTI=tl1><img+src=1+onerror="alert('And+now+on+'+document.domain)"+x; Domain=.google.com; Path=/";
document.location="https://mail.google.com/mail/x/";
</script> 複制
讓我們看看發生了什麼：
1、系統會顯示 plus.google.com 上的彈窗
2、cookie
GMAIL_NOTI
中被設定了 xss 代碼，mail.google.com 會讀取這條 cookie 進而被 xss 攻擊
3、使用者會立即重定向到 mail.google.com 進而被 xss 攻擊
您可以在下面的視訊中看到結果：
這兩個漏洞已經在 2014 年 3 月報告給了 Google，并且已經被修複。非常感謝 Google 安全團隊的，這是一個鍛煉技能的好方法。
總結
這是一篇 2014 年的文章，雖然文中的平台已經改進了，但是技術的本質沒有變化。
mail.google.com
本身是沒有 xss 漏洞的，但讀取了從
plus.google.com
傳來的 cookie 時，并沒有進行過濾，安全問題就由此産生了。
cookie 中的資料一般是由伺服器分發的，是以在開發中很難想到 cookie 中的資料也是不安全的。這裡其實有兩個辦法來解決這個問題：
1、對 cookie 的資料進行過濾；
2、正确設定 cookie 的作用域。
兩個方法如果實施了任意一個都可以防止 xss 的産生。從現在來看，浏覽器的的存儲空間不僅僅有 cookie，還有 sessionStorage、localStorage、IndexedDB。從這些來源的資料在處理時也需要被謹慎考慮。