TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Target=”_blank” is an underestimated vulnerability

183 点作者 SimplyUseless大约 9 年前

19 条评论

Cpoll大约 9 年前
For anyone that wants to see this in action:<p>- Open a website, let&#x27;s say google.com<p>- Open a console and type in `window.open(&quot;<a href="http:&#x2F;&#x2F;xkcd.com&quot;)`" rel="nofollow">http:&#x2F;&#x2F;xkcd.com&quot;)`</a><p>- Disable your popup blocker and do it again.<p>- Open a console in the new xkcd window and type in `window.opener.location = &quot;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;user?id=Cpoll&quot;`" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;user?id=Cpoll&quot;`</a><p>Note that Google quietly turned into my profile page. Now, imagine that it instead turned into maliciousgoogle.com, which looks just like Google, and you can see the attack vector.
评论 #11632635 未加载
评论 #11633518 未加载
评论 #11633462 未加载
throwawaybookst大约 9 年前
<i>&gt; PS. Interestingly, Google doesn’t seem to care.</i><p>That&#x27;s not fair. They state it&#x27;s a problem that is inherent to browsers, not that they don&#x27;t care about the issue.<p>Also be mindful of Google&#x27;s warning regarding the author&#x27;s workaround:<p><i>&gt; in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones.</i>
评论 #11632005 未加载
nmjohn大约 9 年前
&gt; The newly opened tab can then change the window.opener.location to some phishing page.<p>This is true, and is a vulnerability I have been looking at for a while now, though I&#x27;ve not actually seen it exploited yet in the real world. For anyone interested, there are some pretty interesting exploits involving pages where an auth token is in the querystring and thus sent in the referer field by the browser. Also, consider what happens when you use an alert() in javascript to yank context back to the now attacker controlled tab...<p>&gt; Or execute some JavaScript on the opener-page on your behalf…<p>Not true, this implies the &quot;attacker&quot; can run javascript in the context of the original page. They can only run javascript after redirecting the original page to one they control, so it&#x27;s not like they can run code on the facebook.com domain, which would be a _huge_ exploit.
评论 #11632324 未加载
zerd大约 9 年前
I guess this is the trick 99% of porn sites use to do &quot;pop-unders&quot; now. Shouldn&#x27;t the fix for this be in the browers?
评论 #11632838 未加载
bluesmoon大约 9 年前
Looks like an almost verbatim copy of <a href="https:&#x2F;&#x2F;mathiasbynens.github.io&#x2F;rel-noopener&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mathiasbynens.github.io&#x2F;rel-noopener&#x2F;</a>
dmnd大约 9 年前
At Flexport, a security audit revealed we were vulnerable to this. So we made a linter to detect it. If you use React like we do, maybe our linter will be useful to you too: <a href="https:&#x2F;&#x2F;github.com&#x2F;yannickcr&#x2F;eslint-plugin-react&#x2F;pull&#x2F;582" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;yannickcr&#x2F;eslint-plugin-react&#x2F;pull&#x2F;582</a>
oneeyedpigeon大约 9 年前
So quite apart from being a crime against usability, now it turns out target=&quot;_blank&quot; is a great big security hole, too. I fear this isn&#x27;t going to be solved &#x27;the flash way&#x27; (i.e. by ditching it altogether) but just by making window.opener.location read-only (but maybe only for different domains). One can still dream, though.
idoco大约 9 年前
I was really surprised to find out that this works in chrome, since the &quot;site-per-process&quot; policy was one of the major ideas that google implemented and advocated - and different processes shouldn&#x27;t have access to the same memory space.<p>But then I read this - <a href="https:&#x2F;&#x2F;www.chromium.org&#x2F;developers&#x2F;design-documents&#x2F;site-isolation" rel="nofollow">https:&#x2F;&#x2F;www.chromium.org&#x2F;developers&#x2F;design-documents&#x2F;site-is...</a><p>&quot;Most renderer-initiated navigations (including link clicks, form submissions, and scripted navigations) are kept within the current process even if they cross a site boundary. This is because other windows in the same process may attempt to use postMessage or similar calls to interact with them.&quot;
simonw大约 9 年前
This article is incorrect about this being a vector for executing JavaScript (the same origin policy prevents that), but the phishing potential from redirecting the opener page to a fake URL is definitely cause for concern.
joveian大约 9 年前
Is there a canonical safe way to pop up a link in a new tab&#x2F;window? This seems like a major bug and hopefully browser vendors will fix it quickly.
评论 #11634257 未加载
koolba大约 9 年前
In what world would a cross domain version of this be a good idea? <i>Maybe</i> there&#x27;s a legit use case within the same domain (think 90&#x27;s HTML frames), but cross domain?!<p>Actually thinking about it more, it&#x27;s same world that connects to remote servers over plaintext telnet. Oh and you don&#x27;t need to verify your identity either, user&#x27;s will just say who they are and we&#x27;ll trust them.
bandrami大约 9 年前
Which points to the fact that target= is a very bad idea in the first place. As a web developer, it&#x27;s not my concern or business what window&#x2F;tab combination my reader views a link in (mechanism vs. policy and all). If I decided to hijack the browser&#x27;s and user&#x27;s preferred target policy, then yeah, I&#x27;m opening myself up to some exposure to what that link does.
dakull大约 9 年前
Twitter&#x27;s t.co links seem to mitigate this by issuing a 301 to the actual link thus fixing the `window.opener.location` vulnerability.<p>I wonder if the reasons for implementing this are related or just good riddance :)
评论 #11633065 未加载
G3E9大约 9 年前
For you Firefox users, try the add-on RequestPolicy (<a href="https:&#x2F;&#x2F;requestpolicycontinued.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;requestpolicycontinued.github.io&#x2F;</a>) and before a site opens or redirects to another domain, you&#x27;ll be prompted (you can make policies around your decision for future instances.)
wmil大约 9 年前
It seems like there&#x27;s an easy fix... infer &#x27;rel=noopener&#x27; by default on every https site that opens an http site. Or just don&#x27;t allow http pages to redirect https pages.<p>It would make scam pages much more expensive while still allowing most legitimate use. And it would be consistent with existing security policies.
评论 #11633481 未加载
评论 #11633309 未加载
gcr大约 9 年前
This is not a very informative article. It doesn&#x27;t explain <i>how</i> the attack works (e.g. what is the window.opener object? how can an attacking page modify it? what&#x27;s the trick and why is it important?).
评论 #11633855 未加载
rpedela大约 9 年前
How are rel=noreferrer and rel=noopener equivalent in Firefox?
评论 #11632525 未加载
brador大约 9 年前
What to use instead if I need the link to open in a new tab&#x2F;window?
LunaSea大约 9 年前
I reported this issue to Google, Facebook and GitHub. Google and Facebook were not interested and GitHub was already working on a fix.
评论 #11632753 未加载