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

罗武  等:浏览器同源策略安全研究综述                                                             2489


                    •   如果 data.js 中调用了特定函数来返回共享资源(my_callback({‘data’:data})),攻击者网页可以通过先定
                        义 my_callback 函数,再内联 data.js 来恶意获取资源.
                    •   如果 data.js 中调用了对象成员函数来返回共享资源(System.TransactionData.Fetch({‘data’:data})),攻击
                        者可以通过事先依次定义对象(System.TransactionData)与对象成员 Fetch 函数来恶意获取资源.
                    •   如果 data.js 允许通过 URL 来指定回调函数,攻击者可以通过自定义函数来恶意获取资源.例如,当 URL
                        为 https://bob.com/data.js?callback=my_callback 时,data.js 将调用 my_callback 函数.此时,攻击者网页可
                        以通过定义 my_callback 函数,再内联以上 URL 的脚本来获取资源.
                    •   如果 data.js 利用 URL 指定的字段并加入数字来指定回调函数,攻击者可以通过先遍历所有可能的回
                        调函数名称,并定义对应函数来获取资源.
                    最后,攻击者网页可以通过网络通信来将获取的恶意数据返回给攻击者服务器.此外,Grossman                              [75] 发现,可
                 以攻击使用 JSON-P 机制的 Google 邮件网站.当用户事先登录了 Google 邮件网站后,浏览器中维护了用户对应
                 的 cookie.当用户 cookie 没有过期的情况下,用户被诱导访问了攻击者网页,该攻击者网页嵌入了 Google 邮件网
                 站的脚本(如 http://mail.google.com/mail/?_url_scrubbed_来获取联系人列表).由于浏览器在发送网络请求时会
                 自动携带对应的 cookie,Google 邮件服务器将会返回受害者用户的联系人列表.联系人列表在 JavaScript 中将会
                 转为数组 Array,攻击者网页可以通过事先重载 Array 对象来读取联系人列表.这种攻击是 XSSI 攻击(见第 3.1.1
                 节)的一个例子,JSON-P 机制为发起 XSSI 攻击创造了条件.
                 4.2.2    CORS 跨域资源共享
                    (1)  机制概述
                    Web 的 Fetch 标准 [95] 定义了 CORS 机制的基本规范,来允许一个 frame 获取跨源服务器的网络响应.CORS
                 中定义了两类请求:简单请求与非简单请求.前者要求请求方法为 HEAD,GET 或 POST,且 HTTP 头信息为预先
                 定义的几种字段(如 Accept,Content-Language 等);后者采用诸如 PUT,DELETE 之类的请求方法,或使用一些其
                 他的 HTTP 头字段.非简单请求被认为是可能存在安全风险的网络请求.
                    对于简单请求,CORS 要求浏览器在发送网络请求时增加名为 ORIGIN 的 HTTP 头,用来说明请求网页的源;
                 若目标服务器允许该源访问,则在网络响应中增加 Access-Control-Allow-Origin 的 HTTP 头,值为服务器允许访
                 问网络响应的源;浏览器在收到网络响应后,仅当请求网页的源被包含在 Access-Control-Allow-Origin 中时,才
                 允许请求网页访问网络响应.
                    非简单请求需要事先执行预检协议(preflight).在预检协议中,浏览器采用 OPTIONS 请求方法,其中包含了
                 Access-Control-Request-Method 来指定跨源请求的请求方法(如 PUT)以及 Access-Control-Request-Headers 来表
                 示跨源请求中特殊或者自定义的 HTTP 头字段.服务器若允许该源访问资源,将返回 Access-Control-Allow-
                 Origin,Access-Control-Allow-Methods 与 Access-Control-Allow-Headers 来表示允许资源共享的源、请求方法以
                 及 HTTP 头;当浏览器发现服务器允许时,将执行简单请求对应的协议来让网页访问跨源服务器数据.此外,为了
                 提高性能,CORS 机制还提供了 Access-Control-Max-Age 头字段来让浏览器缓存预检协议的结果.
                    (2)  安全威胁
                    Chen 等人 [16] 对 CORS 在现实世界网页中的实际应用进行了实证研究.通过对 CORS 的设计、实现和部署
                 的分析,他们发现,CORS 受到许多新的安全问题的影响.考虑到这些安全风险,Chen 等人提出了一些建议来对协
                 议进行简化和澄清,包括对简单请求也进行对应的预检、对简单请求携带的 HTTP 头与内容的格式与编码等进
                 行额外的限制等.其中一些建议已经被 CORS 规范和主流浏览器采用.
                    CORS 机制的第 1 类安全风险,是 CORS 协议实现放宽了跨源“写”特权.CORS 对于简单请求没有预检阶段.
                 对于简单请求中允许的 9 个 HTTP 头字段,RFC7231 中明确指出其中的 4 个字段有格式的限制(如 Accept、
                 Accept-Language、Content-Language 以及 Content-Type).然而目前,主流浏览器中只有 Safari 进行了格式限制,
                 而且所有主流的浏览器对 Content-Type 字段的限制都是基于前缀匹配.这意味着攻击者网页在简单请求中携
                 带恶意负载,服务器对 HTTP 头信息不安全的解析将造成安全威胁.Chen 等人证明了,不安全的格式检查能够使
   202   203   204   205   206   207   208   209   210   211   212