Chrome-Site_App Isolation-Site隔离_App隔离.pdf

关于Firefox的技巧的文档:侧边栏视图、缩略图视图,这里文章基本都是出自本人之手,我可以保证原创性 Site/AppIsolationVSABE 多浏览器/多配置模型: Google团队在该报告中的贡献: SSBs 在单浏览器中实现Site/AppIsolation 多浏览器/配置的好处: Site/AppIsolation的局限: 下面对表中的跨站型/非同源攻击进行详细解释: 哪些特点使但浏览器/配置模式会暴露如上这么多的漏洞呢?总结起来就3点: 定义IsolatedSites/Apps: 通过HTTPHeader初始化: Chrome的实现: 设计目标: 威胁模式: Chrome实验性试用: ///site-isolation, ///isolated-sites, //ccs-, //该项目进展, Site/AppIsolationVSABE ●比如SiteIsolation安全保护出于的2个关键地方: 入口限制:类似于ABE的一条规则:AcceptfromSELF++ 状态信息隔离:类似于ABE的一条规则:Anonfrom* ●再比如,SiteIsolation使用2种策略组: 内置,需要下载:等价于ABE的第三方规则+系统规则网站定义策略组:等价于ABE的网站规则●再比如,使用文件下载规则,相同============================================================= 多浏览器/多配置模型: Site隔离还处于实验阶段的安全机制,因为真正实现站点隔离需要考虑到对内存的额外需求,沙盒的使用对性能的影响,Site信息传递等安全专家一直建议使用多配置/浏览器上网:一个配置用来冲浪,一个配置用来登录敏感Sites; 从这个观点出发,产生2个疑问:多浏览器配置真的可以实现安全性能增强么,如果可以那么哪些属性起到关作用了?是否可以在同一个浏览器中实现多个配置共存? 很多安全机制都是互相借鉴思想的,Site/AppIsolation与ABE的思想几乎是一样的,这一点知道读了下面这个论文后才会更加体会到: (Firefox用户早就可以实现了,而且之前法和早已经提出了这种思想) 以反射型XSS举例,攻击者制作一个恶意的URL,其中包含了一串攻击代码,然后把用户的浏览器导航到该URL,诱使合法Site回应该恶意攻击代码。如果使用了2个配置,那么当用非敏感配置浏览时,某个银行网站上的一个恶意URL是无法获取到用户的帐户信息的。多浏览器/多配置的好处主要来自2个:状态信息隔离、入口限制●状态信息隔离:一个浏览器内的代码无法获取和共享另一个浏览器的同意Site的状态/授权信息●入口限制:即从一个浏览器进入某个敏感Site的方式是有限的,从而避免了之前那种反射型URL方式进入某个敏感Site的可能,从而也进一步确保了状态信息的隔离状态信息隔离是很关键/重要的,比如历史嗅探-HistorySniffing、缓存时间攻击-cachetimingattacks等攻击无须通过恶意URL代码来实现,也就是说关于入口限制是不够的,比如使用状态信息隔离技术。不仅是这些Web应用的漏洞,状态信息隔离甚至还能保护敏感Site免受对浏览器漏洞的利用。此外,Site隔离的好处还有对多Sites的访问控制上,我们可以使用白名