[譯] 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。從這些來源的資料在處理時也需要被謹慎考慮。