Page 202 - 《软件学报》2021年第8期
P. 202

2484                                   Journal of Software  软件学报 Vol.32, No.8,  August 2021

                        御机制(见第 3.2.2 节)以及应对不同源 frame 过度授权的同源策略增强机制(见第 3.3.2 节).实现强隔离
                        的优势在于普适性,即不需要对不同的场景与新型策略给出不同的解决方案.但强隔离机制的实现意
                        味着需要设计合理且安全的资源共享机制,并将引入额外的开销.例如,实现脚本之间的强隔离机制
                        TreeHouse 系统带来了接近 15 倍的网页加载开销          [30] ,实现同源不同 frame 之间强隔离的 COWL 系统
                        也带来了 16%的开销      [60] .这意味着实现强隔离的防御机制需要进一步优化,以保证隔离与资源共享的
                        开销是在可接受的范围内.
                    •   实现权限控制:产生以上安全威胁的原因之一是新型场景与策略要求更细粒度的权限控制.例如,内容
                        安全策略作用于 frame 上,从而导致同源不同 frame 被赋予了不同的权限                 [10] ;但 Web 应用开发者可以利
                        用 CSPAutoGen [68] 等系统来为同源的所有 frame 设置相同的内容安全策略规则,从而消除同源不同
                        frame 权限的不一致性.此类防御方案通常针对于特定的场景或者策略,并且对目前 Internet 上的网站
                        可能带来兼容性问题,如 CSPAutoGen 系统对 Alexatop 50 网站中的 22 个网站的 UI 产生了细微的变化.
                        然而,这一类机制不需要对同源策略规则进行变化,因而通常不需要对浏览器进行修改或需要网页开
                        发者对编写习惯进行调整,并能对新型策略的设计与配置提供安全保障.
                              Table 6    Comparison on defenses against the limitations of same-origin policy
                                          表 6   针对同源策略规则不足的防御方案对比
                                                                                             浏览器是否
                      防御方案           方案目标            网页加载开销               兼容性/可用性
                                                                                              需要修改
                                     实现脚本           限制 Alexatop 500     脚本之间的函数调用
                          [44]
                       Jate                                                                     是
                                   之间的强隔离         网站的广告脚本:19.5%        必须通过代理对象完成
                                     实现脚本           限制基于 DOM 的         脚本之间的函数调用必须
                            [30]
                     TreeHouse                                                                  否
                                   之间的强隔离            游戏网页:15 倍         使用消息通信机制完成
                                     实现脚本            限制 4 种广告          脚本之间的函数调用必须
                           [50]
                      AdJail                                                                    否
                                   之间的强隔离             脚本:4.08%         使用消息通信机制完成
                                                  限制 Alexatop 200 网站:
                                    实现 frame                             Alexa top 100 网站:
                          [9]
                       COP                         累计分布曲线在有无                                    是
                                   之间的强隔离                                   完全兼容
                                                  COP 情况下基本一致
                      COWL [60]     实现 frame         限制加密文档                完全向后兼容               是
                                   之间的强隔离             编辑器:16%
                    CSPAutoGen [68]    实现同源不同        限制 Alexa top   Alexatop 50 网站:28 个网站兼容、    否
                                 frame 权限的一致性        500 网站:9.1%     22 个网站在 UI 上有极小区别
                                 利用 Referer 字段实现                     在 HTTPS 协议上,仅有 0.05%~
                           [11]
                      Barth 等                            −                                      是
                                 不同源之间的强隔离                          0.22%的浏览器取消 Referer 字段

                 3.5   小   结
                    同源策略规则的设计在考虑安全性的同时,需要满足 Web 应用所需的功能,因而允许了诸如允许发送跨源
                 网络请求与嵌入第三方脚本等操作,从而造成同一个 frame 中第三方脚本的过度授权、同源不同 frame 的过度
                 授权、甚至不同源 frame 的过度授权.这些安全威胁是策略设计对使用便利性的妥协,也意味着安全的浏览器环
                 境必须要求策略设计者更合理的策略构建以及 Web 应用开发者更安全的网页编写.Web 应用开发者不应盲目
                 依靠同源策略来确保网站安全,还需要深入了解同源策略规则,并采取一系列的方案来应对一些同源策略规则
                 所带来的不足.
                 4    跨域/跨源通信机制安全威胁及应对

                    浏览器根据同源策略来控制 JavaScript 代码对资源的访问,然而随着 Web 的发展与 Web 应用功能的复杂
                 化,越来越多的需要宽松的同源策略场景随之出现.这些场景可以分为两类:一是同父域名下跨源通信,二是不
                 同域名下的跨域通信.在第 1 类场景下,一个域名的所有者需要搭建多种服务(如邮件、搜索以及新闻等),这些服
                 务分别搭建在不同的子域名下,但是有可能需要互相交互;在第 2 类场景下,一个网站希望借助于第三方的网站
                 来完成某些特定任务,如用户追踪和性能分析等,该网站需要将某些数据分享给第三方网站.
   197   198   199   200   201   202   203   204   205   206   207