免费黄色片网址,国产a区,久久三级影院

FaceBook的存儲(chǔ)型XSS漏洞

責(zé)編：mhshi ｜2018-03-21 13:33:41

Open Graph協(xié)議

當(dāng)您在Facebook發(fā)帖中添加URL時(shí)，F(xiàn)acebook將使用Open Graph協(xié)議顯示豐富的內(nèi)容。以下是關(guān)于Facebook如何使用OG在Facebook帖子中嵌入外部?jī)?nèi)容的大致流程：

攻擊者在Facebook帖子上發(fā)布URL
Facebook服務(wù)器讀取URL（服務(wù)器端）并讀取OG meta標(biāo)簽中提取有關(guān)URL內(nèi)容的信息（例如，內(nèi)容是帶有標(biāo)題，封面圖像，視頻編碼類(lèi)型和視頻文件URL的視頻）
受害者查看帶有封面圖片和播放按鈕Facebook帖子
當(dāng)受害者點(diǎn)擊播放按鈕時(shí)，視頻會(huì)使用從OG元標(biāo)記中提取的視頻信息加載。（XSS將在這里執(zhí)行）

許多網(wǎng)站也使用OG工作流，包括Twitter和WordPress等。

步驟#2很敏感：服務(wù)器端讀取用戶提供的URL，這通常會(huì)導(dǎo)致SSRF。
如果托管網(wǎng)站在敏感網(wǎng)頁(yè)上使用X-Frame-Options：SAMEORIGIN并允許攻擊者在同一子域中注入任意iframe，則會(huì)造成潛在的點(diǎn)擊劫持漏洞。

FB不容易受到這些問(wèn)題的影響

有趣的部分在步驟#4：在受害者點(diǎn)擊播放按鈕后，F(xiàn)B加載視頻時(shí)。首先，F(xiàn)B會(huì)發(fā)送一個(gè)XHR請(qǐng)求來(lái)獲取視頻類(lèi)型和視頻文件URL，它們都是由攻擊者在ogvideo：type（我們稱(chēng)之為ogVideoType）和og：video：secure_url（ogVideoUrl ）由攻擊者發(fā)布的URL的標(biāo)簽。以下是OG元標(biāo)記的示例：

<!DOCTYPE html>
<html>
<head>
<meta property="og:video:type" content="video/flv">
<meta property="og:video:secure_url" content='https://example.com/video.flv'>
<meta property="og:video:width" content="718">
<meta property="og:video:height" content="404">
<meta property="og:image" content="https://example.com/cover.jpg">
(...)
</head>
<body>
(...)
</body>
</html>

If ogVideoType is “iframe” or “swf player” then FB loads an external iframe and doesn’t handle the playing of the video. Otherwise, FB was using MediaElement.jsto handle the loading of the video directly on facebook.com. I already reported and disclosed vulnerabilities on the Flash component of ME.js on both Facebook and WordPress.

如果ogVideoType是“iframe”或“swf player”，則FB會(huì)加載一個(gè)外部iframe并且不處理該視頻的播放，而是直接使用MediaElement.js在facebook.com上處理視頻加載。我已經(jīng)報(bào)告并披露了ME.js的Flash組件在Facebook 和WordPress上的漏洞。

使用FlashMediaElement.swf造成的存儲(chǔ)型XSS

MediaElements.js根據(jù)ogVideoType會(huì)有多種播放視頻的方式。

如果ogVideoType是“video / flv”（flash視頻），則Facebook在facebook.com上加載Flash文件FlashMediaElement.swf（使用<embed>標(biāo)簽），并將ogVideoUrl傳遞到FlashME.swf進(jìn)行視頻播放。FlashME.swf然后將日志信息發(fā)送到facebook.com（使用Flash-to-JavaScript）關(guān)于“視頻播放”或“視頻結(jié)束”等事件。FlashME.swf正確處理了Flash-to-JavaScript的通信，特別是被正確轉(zhuǎn)義為\以避免XSS。

但是，發(fā)送的JavaScript代碼是：

setTimeout('log("[VIDEO_URL]")', 0)

在Javascript中setTimeout與eval類(lèi)似，它會(huì)將字符串轉(zhuǎn)換為指令，使其非常危險(xiǎn)

[VIDEO_URL]由攻擊者控制，它是ogVideoUrl的值。如果它包含“例如

http://evil.com/video.flv?"[payload]

Flash會(huì)將以下指令發(fā)送給javascript：

setTimeout("log(\"http://evil.com/video.flv?\"payload\")", 0);

如您所見(jiàn)，“ in video.flv？”payload已正確轉(zhuǎn)義，因此攻擊者無(wú)法逃離setTimeout函數(shù)。

但是，當(dāng)JavaScript執(zhí)行setTimeout函數(shù)時(shí)，它將執(zhí)行以下JavaScript指令：

log("http://evil.com/video.flv?"[payload]")

而這次“不再逃脫，攻擊者可以注入XSS！

現(xiàn)在的問(wèn)題是，F(xiàn)acebook在將ogVideoUrl傳遞給FlashME.swf之前是否會(huì)轉(zhuǎn)義l。

首先，F(xiàn)acebook JavaScript向Facebook服務(wù)器發(fā)送XHR請(qǐng)求以獲取ogVideoType和ogVideoUrl的值。ogVideoUrl的值是正確編碼的，但它可以包含任何特殊字符，例如：

https://evil.com?"'<

然后，在發(fā)送到Flash之前，ogVideoUrl進(jìn)行了如下轉(zhuǎn)換：

function absolutizeUrl(ogVideoUrl) {
var tempDiv = document.createElement('div');
tempDiv.innerHTML = '<a href="' + ogVideoUrl.toString().split('"').join('&quot;') + '">x</a>';
return tempDiv.firstChild.href;
}flashDiv.innerHTML ='<embed data-original="FlashME.swf?videoFile=' + encodeURI(absolutizeUrl(ogVideoUrl )) +'" type="application/x-shockwave-flash">';

absolutizeUrl（ogVideoUrl）的結(jié)果在發(fā)送到Flash之前進(jìn)行了URL編碼，但當(dāng)Flash接收到數(shù)據(jù)時(shí)，它會(huì)自動(dòng)對(duì)其進(jìn)行URL解碼，因此我們可以忽略encodeURI指令。

absolutizeUrl使用當(dāng)前的javascript上下文的協(xié)議和域(Domain)來(lái)將相對(duì)URL轉(zhuǎn)換為絕對(duì)URL（如果提供了絕對(duì)URL，則返回它幾乎不變）。這似乎是“哈克”，但它看起來(lái)足夠安全和簡(jiǎn)單，因?yàn)槲覀冏尀g覽器做了艱苦的工作。但當(dāng)存在特殊字符編碼時(shí)，這并不簡(jiǎn)單。

當(dāng)最初分析這段代碼時(shí)，我使用的是Firefox，因?yàn)樗泻馨舻臄U(kuò)展，比如Hackbar，Tamper Data和Firebug！

在Firefox中，如果你嘗試

absolutizeUrl('http://evil.com/video.flv#"payload')

它會(huì)返回

http://evil.com/video.flv#%22payload

所以我被難住了，因?yàn)樵贔acebook中，由Flash發(fā)送的JavaScript指令會(huì)是

setTimeout("log(\"http://evil.com/video.flv?%22payload\")", 0);

這將導(dǎo)致

log("http://evil.com/video.flv?%22[payload]")

這不是一個(gè)XSS。

然后我嘗試了Chrome和

absolutizeUrl('http://evil.com/video.flv#"payload')

http://evil.com/video.flv#"payload

和 o / YEAH !!!!!

現(xiàn)在Flash發(fā)送

setTimeout("log(\"http://evil.com/video.flv?\"payload\")", 0);

到Facebook的JavaScript和哪些將導(dǎo)致

log("http://evil.com/video.flv?"[payload]")

所以如果ogVideoUrl設(shè)置為

http://evil.com/video.flv#"+alert(document.domain+" XSSed!")+"

那么Facebook將執(zhí)行

log("http://evil.com/video.flv?"+alert(document.domain+" XSSed!")+"")

并會(huì)顯示一個(gè)不錯(cuò)的小警告框，說(shuō)“facebook.com XSSed！”

這是由于瀏覽器解析URL時(shí)，不同的瀏覽器在特殊字符編碼上有所不同：

Firefox將對(duì)URL中出現(xiàn)的任何雙引號(hào)(“)進(jìn)行URL編碼
Chrome瀏覽器（最高版本為64）將除了URL 的hash部分（=fragment
）外的雙引號(hào)(“)進(jìn)行URL編碼。（請(qǐng)注意：在Chrome的最新版本65中，此行為已更改，現(xiàn)在Chrome的行為與Firefox相同，在hash中的雙引號(hào)（”）也會(huì)進(jìn)行編碼）
IE和Edge將不會(huì)URL編碼在hash部分或者URL 的搜索部分（=query）中的雙引號(hào)
Safari將不會(huì)URL編碼在hash部分的雙引號(hào)(“)

正如你所看到的讓瀏覽器決定如何在JavaScript代碼中的URL中進(jìn)行特殊字符編碼并不是很好！

我立即將此漏洞報(bào)告給Facebook，他們?cè)诘诙旎貜?fù)并告訴我他們修改了Flash文件，以便它不再使用setTimeout，F(xiàn)lash現(xiàn)在會(huì)發(fā)送

log("http://evil.com/video.flv?\"payload")

正如你所看到的“正確地轉(zhuǎn)義到”，所里這里不再有XSS。

無(wú)Flash存儲(chǔ)XSS

上面的的XSS需要Flash，所以我檢查這里能否有一個(gè)不使用Flash的payload。

如果ogVideoType是“video / vimeo”，則會(huì)執(zhí)行以下代碼

ogVideoUrl = absolutizeUrl(ogVideoUrl);ogVideoUrl = ogVideoUrl.substr(ogVideoUrl.lastIndexOf('/') + 1);playerDiv.innerHTML = '<iframe data-original="https://player.vimeo.com/video/' + ogVideoUrl + '?api=1"></iframe>';

正如你可以看到 absolutizeUrl（ogURL）在注入playerDiv.innerHTML之前沒(méi)有被urlencoded，所以當(dāng)ogVideoUrl設(shè)置為

http://evil.com/#" onload="alert(document.domain)"

playerDiv.innerHTML則會(huì)變?yōu)椋?/p>

<iframe data-original="https://player.vimeo.com/video/#" onload="alert(document.domain)" ?api=1"></iframe>

這又是Facebook.com上的XSS！

我在前一個(gè)XSS被修復(fù)的同一天報(bào)道了這一點(diǎn)，F(xiàn)acebook在同一天用如下方法修復(fù)了漏洞：

ogVideoUrl = absolutizeUrl(ogVideoUrl);ogVideoUrl = ogVideoUrl.substr(ogVideoUrl.lastIndexOf('/') + 1);playerDiv.innerHTML = '<iframe data-original="https://player.vimeo.com/video/' + ogVideoUrl.split('"').join('&quot;') + '?api=1"></iframe>'

第二天，我發(fā)現(xiàn)了另一個(gè)易受攻擊的點(diǎn)：當(dāng)ogVideoType是未知的類(lèi)型，比如“video / nothing”時(shí)，F(xiàn)acebook會(huì)顯示一條包含ogVideoUrl鏈接的錯(cuò)誤消息，如下所示：

errorDiv.innerHTML = '<a href="' +absolutizeUrl(ogVideoUrl ) + '">'

所以ogVideoUrl 的payload設(shè)置為

https://opnsec.com/#"><img/src="xxx"onerror="alert(document.domain)

errorDiv.innerHTML則會(huì)變?yōu)椋?/p>

<a ><img data-original="xxx" onerror="alert(document.domain)">

我把它報(bào)告給了Facebook，非常歡樂(lè)的是，來(lái)自Facebook的白帽子Neil告訴我，他計(jì)劃在第二天檢查這些代碼！

另一種可能的ogVideoType是“silverlight”。Silverlight 是微軟公司的瀏覽器插件，它能與VBscript交互，就像Flash和JavaScript交互。

在Facebook（silverlightmediaelement.xap）上托管的silverlight文件是這樣加載的：

params = ["file=" + ogVideoUrl, "id=playerID"];silverlightDiv.innerHTML ='<object data="data:application/x-silverlight-2," type="application/x-silverlight-2"><param name="initParams" value="' + params.join(',').split('"').join('&quot;') + '" /></object>';

silverlightmediaelement.xap然后會(huì)發(fā)送日志信息到Facebook的JavaScript（這點(diǎn)有點(diǎn)像Flash），但這次它不包含ogVideoUrl，但只有player ID，這是另一個(gè)在initParams中發(fā)送由Facebook定義的參數(shù)。Silverlight會(huì)調(diào)用javascript函數(shù)[id] _init（） ，其中[id]是“playerID”。

在Silverlight中，參數(shù)不是由 URLs或Flash中的＆所分隔，而是通過(guò)逗號(hào)(,)

如果ogVideoUrl 包含一個(gè)逗號(hào)( ，)那么在這個(gè)逗號(hào)后面的每一個(gè)東西都將被silverlight視為另一個(gè)參數(shù)，這意味著使用有效載荷

https://opnsec.com/#,id=alert(document.domain)&

然后silverlight像這樣加載：

silverlightDiv.innerHTML ='<object data="data:application/x-silverlight-2," type="application/x-silverlight-2"><param name="initParams" value="file=https://opnsec.com/#,id=alert(document.domain)&,id=playerID" /></object>';

Silverlight將僅考慮id的第一次出現(xiàn)，并將其值設(shè)置為

alert(document.domain)&

然后Silverlight將調(diào)用以下javascript：

alert(document.domain)&_init()

這意味著再次 XSS！

結(jié)論

我學(xué)到了很多東西，并且發(fā)現(xiàn)這些漏洞非常有趣。我希望你也喜歡它！

以下是一些建議：

Open Graph（以及像json-ld這樣的替代品）是在網(wǎng)站上顯示豐富的外部?jī)?nèi)容的好方法，但你應(yīng)該小心使用（認(rèn)為SSRF，XSS和Clickjacking）

不要讓瀏覽器在您的JavaScript代碼中為您解析URL，每個(gè)瀏覽器都以自己的方式處理它，并且瀏覽器可以隨時(shí)更改其行為（如Chrome 64 – > 65）。應(yīng)該改為使用白名單正則表達(dá)式。

現(xiàn)在的自動(dòng)工具不會(huì)檢測(cè)到使用XHR，DOM突變和外部?jī)?nèi)容的復(fù)雜動(dòng)態(tài)XSS。所以即使是最安全，最有影響力的網(wǎng)站也可能會(huì)受到攻擊。代碼審查和調(diào)試是實(shí)現(xiàn)這些目標(biāo)的方法！

不要害怕大的、壓縮過(guò)、動(dòng)態(tài)的JavaScript源代碼。如果您在網(wǎng)站上發(fā)現(xiàn)一些潛在的危險(xiǎn)功能，您可以放輕松的檢查它是如何實(shí)現(xiàn)的。

原文：https://opnsec.com/2018/03/stored-xss-on-facebook/

上一篇：基于PU-Learning的惡意URL檢測(cè)

下一篇：JbossMiner 挖礦蠕蟲(chóng)分析

压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

FaceBook的存儲(chǔ)型XSS漏洞

压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘免费看|www.tcsft.com