[[374809]]

早在2018年，Chrome就默認(rèn)啟用了站點(diǎn)隔離功能，以緩解UXSS和Spectre等漏洞帶來(lái)的影響。當(dāng)時(shí)，我積極參加了Chrome漏洞獎(jiǎng)勵(lì)計(jì)劃，并在站點(diǎn)隔離機(jī)制中發(fā)現(xiàn)了10多個(gè)漏洞，從而獲得了3.2萬(wàn)美元的獎(jiǎng)勵(lì)。

在本系列文章中，我們不僅會(huì)為讀者解釋站點(diǎn)隔離和相關(guān)安全功能的運(yùn)行機(jī)制，同時(shí)，還會(huì)介紹在該安全機(jī)制發(fā)現(xiàn)的安全漏洞，當(dāng)然，目前這些漏洞已經(jīng)得到了修復(fù)。

挖洞方法

當(dāng)我在Chrome中挖掘安全漏洞的時(shí)候，通常會(huì)從手動(dòng)測(cè)試開始下手，而不是先進(jìn)行代碼審查，因?yàn)镃hrome團(tuán)隊(duì)更擅長(zhǎng)代碼審查。所以我認(rèn)為，但凡從他們的代碼審查中漏網(wǎng)邏輯漏洞，通常都很難通過代碼審計(jì)找到。因此，當(dāng)我開始研究站點(diǎn)隔離時(shí)，我遵循了相同的方法。

什么是站點(diǎn)隔離?

站點(diǎn)隔離是一種安全功能，它將每個(gè)站點(diǎn)的網(wǎng)頁(yè)隔離到單獨(dú)的進(jìn)程中。通過站點(diǎn)隔離機(jī)制，站點(diǎn)的隔離與操作系統(tǒng)級(jí)別的進(jìn)程隔離保持一致，而不是通過同源策略等在進(jìn)程內(nèi)實(shí)現(xiàn)邏輯隔離。

在這里，Site定義為Scheme和eTLD+1(也稱為Schemeful same-site)。

https://www.microsoft.com:443/

因此，Site的定義比Origin更寬泛，Origin是通過Scheme、Host和Port來(lái)進(jìn)行定義的。

https://www.microsoft.com:443/

然而，并不是所有的情況都符合上述Site的定義。因此，我開始測(cè)試下面的邊緣情況，看看站點(diǎn)隔離在每種情況下的表現(xiàn)如何。

不含域名的URL

實(shí)際上，URL并不需要包含域名(例如IP地址)。在這種情況下，站點(diǎn)隔離就變回了同源比較，以實(shí)現(xiàn)進(jìn)程隔離。

File URL

本地文件可以通過文件scheme呈現(xiàn)到瀏覽器選項(xiàng)卡中。目前，站點(diǎn)隔離將使用文件scheme的所有URL都視為源自同一站點(diǎn)。

Data URL

雖然加載在頂部frame上的Data URL始終與它自己的進(jìn)程保持隔離，但加載在iframe內(nèi)的Data URL將從導(dǎo)航發(fā)起方那里繼承Site(盡管源仍然是opaque origin)。年齡較大的讀者可能會(huì)記得類似的概念，iFrame中的Data URL使用的是繼承自Firefox的源。

正如您在上面的圖像中所看到的，即使兩個(gè)示例都導(dǎo)致Microsoft.com嵌入數(shù)據(jù)URL iframe，但是跨站點(diǎn)的情況仍然是保持進(jìn)程隔離的，因?yàn)閷?dǎo)航發(fā)起方是evil.example。

Data URL站點(diǎn)繼承中的漏洞

如果從本地緩存還原瀏覽器或選項(xiàng)卡，那么會(huì)發(fā)生什么情況?這時(shí)，站點(diǎn)隔離機(jī)制還會(huì)記得Data URL的導(dǎo)航發(fā)起方嗎?

事實(shí)證明，還原瀏覽器或選項(xiàng)卡后，站點(diǎn)隔離無(wú)法記住導(dǎo)航啟動(dòng)方。從本地緩存還原選項(xiàng)卡時(shí)，站點(diǎn)隔離通常會(huì)盲目地將Data URL放在父frame的同一站點(diǎn)內(nèi)。攻擊者可以觸發(fā)瀏覽器崩潰，然后還原瀏覽器，從而繞過站點(diǎn)隔離機(jī)制。

從本地緩存還原頁(yè)面時(shí)，可以通過將Data URL隔離到另一個(gè)進(jìn)程中來(lái)解決這個(gè)問題。

具有不透明源的Blob URL

從不透明的源(opaque origin)創(chuàng)建Blob URL(例如Data URL、沙箱iframe或File URL)時(shí)，Blob URL將采用“blob:null/[GUID]”這樣的形式。

由于這是一個(gè)沒有域名的URL，因此，站點(diǎn)隔離機(jī)制將退化為同源比較。但是，這是一個(gè)漏洞，因?yàn)楣粽呖梢酝ㄟ^其他站點(diǎn)創(chuàng)建具有不透明源的Blob URL。而且同源比較還遠(yuǎn)遠(yuǎn)不夠，因?yàn)樵词冀K是“blob:null”。因此，該URL需要同時(shí)對(duì)源和路徑進(jìn)行比較，以進(jìn)行進(jìn)程隔離。

測(cè)試進(jìn)程隔離邏輯

借助于Chromium任務(wù)管理器(Windows中可以通過Shift + Esc組合鍵調(diào)出它)和FramesExplorer等工具，我們?cè)谡军c(diǎn)隔離機(jī)制的進(jìn)程隔離邏輯中發(fā)現(xiàn)了一些問題，這有助于識(shí)別哪些frame共享了同一個(gè)進(jìn)程(此外，您還可以使用chrome://process-internals/#web-contents來(lái)完成同一任務(wù))。

站點(diǎn)隔離如何緩解UXSS攻擊?

從歷史上看，大多數(shù)UXSS攻擊都是通過繞過在渲染器進(jìn)程中實(shí)現(xiàn)的同源策略檢查來(lái)實(shí)現(xiàn)的。換句話說(shuō)，一旦您可以繞過同源策略檢查，所有跨站點(diǎn)數(shù)據(jù)就都可以在渲染器進(jìn)程中使用。因此，JS代碼能夠獲取窗口、文檔或任何其他跨域?qū)ο笠谩?/p>

站點(diǎn)隔離通過隔離進(jìn)程從根本上改變了這一點(diǎn)。也就是說(shuō)，即使您可以繞過同源策略檢查，其他站點(diǎn)的數(shù)據(jù)也無(wú)法在同一進(jìn)程中使用。

此外，將跨域窗口導(dǎo)航到JavaScript URL的UXSS手段也不是問題。我們知道，JavaScript URL導(dǎo)航要想成功，2個(gè)網(wǎng)頁(yè)必須是同源的。因此，對(duì)JavaScript URL的導(dǎo)航可以在渲染器進(jìn)程內(nèi)處理(渲染器應(yīng)該承載任何具有窗口引用的同源網(wǎng)頁(yè))，這樣，任何上傳到瀏覽器進(jìn)程的JavaScript URL導(dǎo)航請(qǐng)求都可以安全地被忽略。當(dāng)然，如果您忘記了在瀏覽器進(jìn)程中忽略JavaScript URL，那就是一個(gè)bug了。

只有進(jìn)程隔離還遠(yuǎn)遠(yuǎn)不夠

站點(diǎn)隔離有助于緩解UXSS，但是進(jìn)程隔離還不足以防止所有跨站點(diǎn)數(shù)據(jù)泄漏。

最簡(jiǎn)單的例子就是Spectre攻擊。借助Spectre攻擊，攻擊者可以讀取進(jìn)程的整個(gè)地址空間。盡管進(jìn)程隔離有助于隔離網(wǎng)頁(yè)，但子資源(例如圖像、音頻、視頻等)不是進(jìn)程隔離的。

因此，在沒有其他緩解措施的情況下，攻擊者可以通過使用img標(biāo)簽嵌入該頁(yè)面來(lái)讀取任意跨站點(diǎn)頁(yè)面。

跨源讀取阻止

跨源讀取阻止(Cross-Origin Read Blocking，CORB)通過檢查跨源子資源中響應(yīng)的MIME類型來(lái)減輕暴露敏感的跨域數(shù)據(jù)的風(fēng)險(xiǎn)。如果跨源子資源的MIME類型在拒絕列表中(例如HTML、XML、JSON等)，則默認(rèn)情況下不會(huì)將響應(yīng)發(fā)送到渲染器進(jìn)程，因此，使用Spectre攻擊將無(wú)法讀取該響應(yīng) 。

繞過CORB

目前，已經(jīng)有多種方法可以繞過CORB。

· CORB bypass in Workers by @_tsuro

· CORB bypass in WebSocket by @piochu

· CORB bypass in AppCache

從根本上說(shuō)，如果使用URLLoader在禁用CORB的情況下獲取了URL，并且響應(yīng)被泄露給了跨站點(diǎn)的Web渲染器進(jìn)程，那么就可以繞過CORB。

例如，我們能夠使用AppCache來(lái)繞過CORB，因?yàn)橛糜谙螺d緩存資源的URLLoader禁用了CORB。據(jù)我所知，AppCache曾經(jīng)允許緩存跨源的HTML文件，所以，我想這可能會(huì)導(dǎo)致CORB被繞過，而且事實(shí)也確實(shí)如此。

同樣需要注意的是，一些渲染器進(jìn)程可以通過某些設(shè)計(jì)(例如擴(kuò)展渲染器進(jìn)程)來(lái)繞過CORB。

跨源資源策略

雖然CORB默認(rèn)情況下可以保護(hù)很多敏感資源，但有些資源(如圖片)可以嵌入Web上的多個(gè)站點(diǎn)中。因此，CORB默認(rèn)情況下不能保護(hù)此類資源進(jìn)入跨源頁(yè)面。

跨源資源策略(CORP)允許開發(fā)人員規(guī)定某些資源是否可以嵌入到同源、同站點(diǎn)或跨源頁(yè)面。瀏覽器可以利用這些規(guī)定來(lái)保護(hù)那些默認(rèn)情況下無(wú)法受到CORB保護(hù)的資源。

通過CORP，網(wǎng)站可以保護(hù)敏感資源免受各種攻擊，如Spectre攻擊、XSSI、特定于子資源的SOP繞過等。換句話說(shuō)，缺少CORP頭部的敏感資源可以使用Spectre攻擊來(lái)讀取(除非資源受到CORB的保護(hù))。

如何測(cè)試CORB

如果您想試驗(yàn)繞過CORB加載子資源(例如，通過上面的AppCache繞過CORB)的想法，請(qǐng)嘗試使用以下響應(yīng)頭部來(lái)加載該子資源：

Content-Type: text/html 
X-Content-Type-Options: nosniff 

 正常情況下，CORB應(yīng)該阻止此類跨域子資源，因此，如果正確加載了子資源，則表明存在CORB繞過漏洞。

如果您想知道在哪些地方不能加載子資源(例如，通過上面的WebSocket繞過CORB)，請(qǐng)使用windbgs!address命令，通過在堆中搜索目標(biāo)字符串，以確認(rèn)它們是否已經(jīng)進(jìn)入渲染器進(jìn)程。

!address /f:Heap /c:"s -a %1 %2 \"secret\"" 

這將在渲染器進(jìn)程的堆內(nèi)存中搜索字符串secret。如果要查找unicode字符串而非ascii字符串，則可以將-a更改為-u。

小結(jié)

借助站點(diǎn)隔離、CORB和CORP保護(hù)機(jī)制，不僅可以緩解從UXSS到Spectre等諸多攻擊，同時(shí)，還能緩解允許攻擊者讀取跨站點(diǎn)信息的其他客戶端漏洞帶來(lái)的危害。但是，有些攻擊可能會(huì)危及渲染器進(jìn)程。在下一篇文章中，我們將集中討論如何進(jìn)一步加強(qiáng)站點(diǎn)隔離機(jī)制，以降低攻擊者通過這種漏洞獲取跨站點(diǎn)信息的風(fēng)險(xiǎn)。

本文翻譯自：https://microsoftedge.github.io/edgevr/posts/deep-dive-into-site-isolation-part-1/如若轉(zhuǎn)載，請(qǐng)注明原文地址。