紐約時報所有2013年前舊文章XSS漏洞

紐約時報所有2013年前舊文章XSS漏洞



跨站腳本攻擊(Cross Site Scripting)，為不和層疊洋式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁面裏插入惡意html代碼，當用護瀏覽該頁之時，嵌入其中Web裏面的html 代碼會被執行，從而達到惡意攻擊用護的特殊目的。


新加坡南洋理工大學物理和數學科學學院博士生王晶(Wang Jing)發現，紐約時報所有2013年前的文章都可已用來攻擊。“2013年前所有包含“PRINT”,”SINGLE PAGE”, “Page” 和“NEXT PAGE” 按鈕的文章都有此漏洞“。










當被問及漏洞的重要性時，王晶回答“對XSS攻擊而言，非常重要的壹件事情是如何說服受害者點擊URL。因為所有的舊文章都可已用來攻擊，所有用護非常容易遭受攻擊“。


研究者王發布了壹個POC視頻和博客說明：

https://www.youtube.com/watch?v=RekCK5tjXWQ

http://tetraph.com/security/xss-vulnerability/new-york-times-nytimes-com-page-design-xss-vulnerability-almost-all-article-pages-are-affected/

王同時說明，紐約時報現在采取了壹種更安全的機制，這種機制不再遭受XSS攻擊。




發布在2013年前的文章是否重要？
問前還是非常嚴重的，因為所有 紐約時報2013年前的文章還在被大量引用。 據此產生的流量也非常大。所以此漏洞及易使紐約時報用護和其他合作者遭受攻擊。

XSS 攻擊後果？
漏洞的危害取抉於攻擊代碼的威力，攻擊代碼也不局限於script。 用護可以被竊取個人資料，重定向到其他頁面等。

參考文章：

http://securitynewswire.com/securitynews2012/article.php?title=XSS_Risk

http://www.tomsguide.com/us/xss-flaw-ny-times,news-19784.html

http://www.hotforsecurity.com/blog/cross-site-scripting-xss-vulnerability

http://news.softpedia.com/news/XSS-Risk-Found-In-Links-to-New-York-Times-Articles-Prior-to-2013-462334.shtml

http://www.hellasforce.com/blog/xss-kindini-entopistikan-se-si

http://telezkope.com/Technology/Programming/3321242/cross-site-scripting

http://worldnew.org/xss-flaw-may-exist-in-the-old-new-york

http://tetraph.wordpress.com/2014/11/01/new-york-times-nytimes-com-page-design-xss-vulnerability-almost-all-article-pages-before-2013-are-affected/

http://tetraph.tumblr.com/post/101472580032/new-york-times

http://www.inzeed.com/kaleidoscope/xss-vulnerability/new-york-times

http://diebiyi.com/articles/%E5%AE%89%E5%85%A8/xss-vulnerability/

http://securityrelated.blogspot.com/2014/10/new-york-times

開心網 (kaixin001.com) OAuth 2.0 Covert Redirect 系統漏洞

Covert Redirect: http://tetraph.com/covert_redirect/Covert Redirect Related to OAuth 2.0 and OpenID:http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html





Kaixin 的 OAuth 2.0 系統可能遭到攻擊。更確切地說， Kaixin 對 OAuth 2.0 系統的 parameter “&redirect_uri“ 驗證不夠充分。可以用來構造對 Kaixin 的 URL跳轉 攻擊。

與此同時，這個漏洞可以用下面的參數來收集第三方 App 和 用戶 的敏感信息（敏感信息包含在 HTTP header裏），

"&response_type"=sensitive_info,token,code...

"&scope"=get_user_info,email...

它也增加了對第三方網站 URL跳轉 攻擊的成功率。

漏洞地點 "/authorize?"，參數"&redirect_uri", e.g.

http://api.kaixin001.com /oauth2/authorize?client_id=232383298458c9b3c19540c63bc4cb0d& response_type=code&redirect_uri=http://store.tv.sohu.com/web /login.do?bru=http://tetraph.com/essayjeans/seasons/祭春.html [1]







同意三方 App 前：

當壹個已經登錄的 Kaixin 用戶點擊上面的 URL ([1]), 對話框會詢問他是否接受第三方 App 接收他的信息。如果同意，他會被跳轉到 參數 "&redirect_uri" 的 URL。

如果沒有登錄的Kaixin 用戶點擊 URL ([1]), 他登錄後會發生同樣的事情。

同意三方 App 後：

已經登錄的 Kaixin 用戶 不會再被詢問是否接受 三方 App。當他點擊 URL ([1]) 時，他會被直接跳轉到攻擊者控制的頁面。

如果 Kaixin 用戶沒有登錄，攻擊依然可以在要求他登錄的Kaixin的對話框被確認後完成（這個過程不會提示任何和三方 App 有關的內容）。





(1) Kaixin 壹般會允許屬於已被驗證過得三方 App domain 的所有 URLs。 然而，這些 URLs 可以被操控。比如，參數 "&redirect_uri" 是被三方 App 設置的，但攻擊者可以修改此參數的值。

因此，Kaixin 用戶意識不到他會被先從 Kaixin 跳轉到第三方 App 的網頁，然後從此網頁跳轉到有害的網頁。這與從 Kaixin 直接跳轉到有害網頁是壹樣的。

因為 Kaixin 的 OAuth 2.0 客戶很多，這樣的攻擊可以很常見。

在同意三方 App 之前，Kaixin 的 OAuth 2.0 讓用戶更容易相信被跳轉的頁面是安全的。這增加了三方 App 被 URL跳轉 攻擊的成功率。

同意三方 App 後， 攻擊者可以完全繞過 Kaixin 的 URL跳轉 驗證系統。







(2) 用了壹個頁面進行了測試， 頁面是 "http://tetraph.com/essayjeans/seasons/祭春.html". 我們可以假定它是有害的，並且含有收集三方 App 和用戶敏感信息的 code。

下面是壹個有漏洞的三方 domain:

sohu.com

這個 domain 有漏洞的 URL:

http://store.tv.sohu.com/web/login.do?bru=http://tetraph.com/essayjeans/seasons/祭春.html

Kaixin 與 sohu.com 有關的有漏洞的 URL:

http://api.kaixin001.com/oauth2/authorize?client_id=232383298458c9b3c19540c63bc4cb0d&response_type=code&redirect_uri=http://passport.sohu.com

POC:

http://api.kaixin001.com /oauth2/authorize?client_id=232383298458c9b3c19540c63bc4cb0d& response_type=code&redirect_uri=http://store.tv.sohu.com/web /login.do?bru=http://tetraph.com/essayjeans/seasons/祭春.html



測試是基於Windows 7 的 IE (9.0.15) 和 Ubuntu (12.04) 的 Firefox (26.0)。













發現者:
王晶, 數學與物理學院, 南陽理工大學, 新加坡
http://www.tetraph.com/wangjing/

參考資料：

http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/

http://tech.firstpost.com/news-analysis/after-heartbleed-major-covert-redirect-flaw-threatens-oauth-openid-and-the-internet-222945.html

http://techxplore.com/news/2014-05-math-student-oauth-openid-vulnerability.html

http://phys.org/news/2014-05-math-student-oauth-openid-vulnerability.html

http://www.tomsguide.com/us/facebook-google-covert-redirect-flaw,news-18726.html

http://news.yahoo.com/facebook-google-users-threatened-security-192547549.html

http://thehackernews.com/2014/05/nasty-covert-redirect-vulnerability.html

http://www.cnbeta.com/articles/288503.htm

http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html

http://baike.baidu.com/link?url=0v9QZaGB09ePxHb70bzgWqlW-C9jieVguuDObtvJ_6WFY3h2vWnnjNDy4-jliDmqbT47SmdGS1_pZ4BbGN4Re_

https://zh.wikipedia.org/wiki

http://www.csdn.net/article/2014-05-04/2819588

http://tetraph.com/covert_redirect/

http://www.zdnet.com/article/over-99-percent-of-about-com-links-vulnerable-to-xss-xfs-iframe-attack/

http://www.hotforsecurity.com/blog/googles-doubleclick-advertising-platform-vulnerable-to-open-redirect-attacks-10822.html

https://www.securityweek.com/xss-xfs-open-redirect-vulnerabilities-found-aboutcom

http://japanbroad.blogspot.jp/2014/11/oauthopenid-facebook.html

兩款互聯網登錄系統曝出重大漏洞 短期內或無法修復 (Covert Redirect)

兩款互聯網登錄系統曝出重大漏洞 短期內或無法修復 (Covert Redirect)





1 安全漏洞

繼OpenSSL漏洞後，開源安全軟件再曝安全漏洞。新加坡南洋理工大學安全研究人員，物理和數學科學學院博士生王晶(Wang Jing )發現，Oauth 2.0， OpenID 授權接口的網站存隱蔽重定向漏洞、英文名為“Covert Redirect”。[1-2] 

2 入侵技術

攻擊者創建壹個使用真實站點地址的彈出式登錄窗口——而不是使用壹個假的域名——以引誘上網者輸入他們的個人信息。[2]







3 漏洞危害

黑客可利用該漏洞給釣魚網站“變裝”，用知名大型網站鏈接引誘用戶登錄釣魚網站，壹旦用戶訪問釣魚網站並成功登陸授權，黑客即可讀取其在網站上存儲的私密信息。[1]

騰 訊，阿裏巴巴，QQ、新浪微博、淘寶網，支付寶，網易，PayPal, eBay, Amazon, Facebook、Google， LinkedIn, Yahoo, VK.com, Microsoft,  Mail.ru, Github, WordPress 等國內外大量知名網站受影響。[1]



鑒 於OAuth和OpenID被廣泛用於各大公司——如微軟、Facebook、Google、以及 LinkedIn——Wang表示他已經向這些公司已經了匯報。Wang聲稱，微軟已經給出了答復，調查並證實該問題出在第三方系統，而不是該公司的自有 站點。Facebook也表示，“短期內仍無法完成完成這兩個問題的修復工作，只得迫使每個應用程序平臺采用白名單”。至於Google，預計該公司會追 蹤OpenID的問題；而LinkedIn則聲稱它將很快在博客中說明這壹問題。[2]







4 背景知識


Oauth是 壹個被廣泛應用的開放登陸協議，允許用戶讓第三方應用訪問該用戶在某壹網站上存儲的私密的信息(如照片，視頻，聯系人列表)，而無需將用戶名和密碼提供給 第三方應用。這次曝出的漏洞，可將Oauth2.0的使用方(第三方網站)的回跳域名劫持到惡意網站去，黑客利用XSS漏洞攻擊就能隨意操作被授權的賬 號，讀取用戶的隱私信息。像騰訊、新浪微博等社交網站壹般對登陸回調地址沒有任何限制，極易遭黑客利用。[1]

(基於百度百科)








參考資料,

http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/

http://tech.firstpost.com/news-analysis/after-heartbleed-major-covert-redirect-flaw-threatens-oauth-openid-and-the-internet-222945.html

http://techxplore.com/news/2014-05-math-student-oauth-openid-vulnerability.html

http://phys.org/news/2014-05-math-student-oauth-openid-vulnerability.html

http://www.tomsguide.com/us/facebook-google-covert-redirect-flaw,news-18726.html

http://news.yahoo.com/facebook-google-users-threatened-security-192547549.html

http://thehackernews.com/2014/05/nasty-covert-redirect-vulnerability.html

http://www.scmagazine.com/covert-redirect-vulnerability-impacts-oauth-20-openid/article/345407/

http://blog.kaspersky.com/facebook-openid-oauth-vulnerable/

http://www.foxnews.com/tech/2014/05/05/facebook-google-users-threatened-bay-new-security-flaw/

http://tech.ifeng.com/internet/detail_2014_05/03/36130721_0.shtml/

http://network.pconline.com.cn/471/4713896.html

http://media.sohu.com/20140504/n399096249.shtml/

http://it.people.com.cn/n/2014/0504/c1009-24969253.html

http://www.cnbeta.com/articles/288503.htm

http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html

http://baike.baidu.com/link?url=0v9QZaGB09ePxHb70bzgWqlW-C9jieVguuDObtvJ_6WFY3h2vWnnjNDy4-jliDmqbT47SmdGS1_pZ4BbGN4Re_

https://zh.wikipedia.org/wiki

http://www.csdn.net/article/2014-05-04/2819588

http://tetraph.com/covert_redirect/

http://www.zdnet.com/article/over-99-percent-of-about-com-links-vulnerable-to-xss-xfs-iframe-attack/

http://www.hotforsecurity.com/blog/googles-doubleclick-advertising-platform-vulnerable-to-open-redirect-attacks-10822.html

https://www.securityweek.com/xss-xfs-open-redirect-vulnerabilities-found-aboutcom

http://japanbroad.blogspot.jp/2014/11/oauthopenid-facebook.html