target='_blank' 安全漏洞示例
更新： Instagram已经解决了这个问题， 极可能是由于这篇文章。Facebook和Twitter仍未解决。我用Instagram做为基本的例子，但主要结论是target="_blank"安全漏洞极为广泛。每一个Web开发者应该警戒它，浏览器也应该考虑修改这个行为。git
若是你在连接上使用 target="_blank"属性，而且不加上rel="noopener"属性，那么你就让用户暴露在一个很是简单的钓鱼攻击之下。为了告知来自于不受保护的站点的用户，咱们运行一个利用了这个缺陷的脚本。程序员
if (window.opener) {
window.opener.location = "https://dev.to/phishing?referrer="+document.referrer;
}
我相信绝大多数站点都没有恰当地处理这个问题，但令我意外的是Instagram.com 也是其中一个。咱们最近恰好建立了 @ThePracticalDev Instagram帐号，而后就发现了这个问题。若是你在咱们的资料页点击 dev.to 连接，而后回到原来的页面，你就会明白个人意思。Twitter也没有在Safari上防备这个安全漏洞，Chrome和Firefox也是。他们没有用 rel="noopener"，所以看起来他们用的安全脚本在Safari上并不起做用。github
更新： 因为Instagram在这篇文章发表以后修复了这个问题，我把下面的例子改为了Facebook的页面。跨域
弄清原委
- 访问The Practical Dev Facebook page.
- 在资料页点击
dev.to连接。这会打开一个新的页卡或窗口。 - 注意，原来的页面已经跳转到这个页面.
当站点在连接中使用target="_blank"来打开新页卡或窗口时，该站点就经过window.opener API给了新页面对原有窗口的访问入口，并授予了一些权限。这其中的一些权限被跨域限制拦截了，可是window.location是漏网之鱼。浏览器
别急，还有更多
这不只存在钓鱼攻击的问题，还涉及到隐私问题，由于新打开的站点对原有页卡的浏览地址有着持续的访问权。它能够轮询这个信息，并获得结果。幸好这个行为看起来被跨域限制阻止了，所以即使我或许能够持续访问你不想让我知道的信息，完整的规范里应该包含健全的限制规则。安全
更新： 在我最开始写这个的时候，我提出了一种浏览器间谍场景，该场景中不良分子能够更完全地侦测用户浏览历史。如今我以为那并不许确，所以我修改了表述。markdown
为了限制 window.opener的访问行为，原始页面须要在每一个使用了target="_blank"的连接中加上一个rel="noopener"属性。然而，火狐不支持这个属性值，因此实际上你要用 rel="noopener noreferrer"来完整覆盖。尽管某些预防措施能够经过脚本实现，正如在Twitter上看到的，但这在Safari上并不起做用。ide
var otherWindow = window.open();
otherWindow.opener = null;
otherWindow.location = url;
这段建议脚原本自于关于该主题的一篇好文章.
这个问题并不知名，并且彻底被低估了。它在Web Hypertext Application Technology Working Group邮件列表中被提出 在我看来，这个浏览器行为的风险远大于潜在的好处。无论怎样，Facebook和Instagram也没有理由忽视这个问题。
将来我还会谈论更多此类事情。 有兴趣能够关注个人Twitter(@bendhalpern) 或 @ThePracticalDev。