Javascript executes in the same origin when using target="_blank" in the <a> tag.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: clonsdale, Unassigned)
References
()
Details
(Keywords: reporter-external, sec-low, Whiteboard: [reporter-external] [client-bounty-form][adv-main107-])
Attachments
(1 file)
|
134 bytes,
text/html
|
Details |
Not sure if I have misunderstood how target="_blank" is meant to operate, but I was under the assumption that any javascript: in the URI should execute in the blank origin. It appears that this works as expected in Chrome and Safari latest versions but not in the latest version of Firefox.
Using a very simple Proof of Concept you can test the behaviour for yourself.
<html>
<head>
<title>App1</title>
</head>
<body>
<a href="javascript:alert(document.domain)" target="_blank">fire</a>
</body>
</html>
From initial testing this PoC doesn't work in Firefox version 83, so perhaps this is a security regression?
Please let me know what you think!
Cheers,
Cameron
Its blocked in version 96 but is reintroduced in version 97 from testing.
|
||
Comment 2•3 years ago
|
||
Passing this from the desktop frontend to the DOM team as it's not a frontend issue.
|
||
Comment 3•3 years ago
|
||
|
|
||
Comment 4•3 years ago
|
||
Nika, do you know what the principal should be for these javascript URIs? Thanks.
|
||
Comment 5•3 years ago
|
||
I think this is one of the ways it is possible to detect bug 1694993. If you run this same test but change the link to be <a href="javascript:alert(document.domain)" target="_blank" rel="opener">fire</a>, it will behave in the same way on chromium based browsers like edge. The difference here is that when we create a new window with noopener (which is the default with "_blank") we don't inhibit origin inheritance into the new tab, meaning that the principal is inherited, and the javascript: URI is able to run with it.
The specific behaviour change which lead to this appearing to become unblocked in version 97 is that Fission was enabled by default on release in that version. When fission is disabled, there is a special mode used to create new pop-up windows in some cases with noopener, which inhibits this principal inheritance (as it is not supposed to be visible). This is disabled with Fission which leads to this issue being observable, though in various cases we'd also take the fission codepath with e10s as the special codepath couldn't handle some edge-cases.
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
||
Comment 6•3 years ago
|
||
This seems like the main issue here is that a website might be relying on very specific and very recent behavior to protect them, which is probably a bad idea, so I'll mark it sec-low. Feel free to adjust it Dan if we're missing something.
Hi @Andrew, is this behaviour that recent? "_blank" target has been supported since at least 2008 as far as I can tell. And rel="noopener" supported by Firefox since version 52 (https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/noopener). It was my impression that these features were designed specifically for security and that there would be a lot of sites which rely on this behaviour to protect them against XSS attacks.
Please let me know if I may be misunderstanding. Thank you!
Cameron
|
||
Comment 8•3 years ago
|
||
It seems that Chrome's behavior might have been a side-effect of the (somewhat recent) behavior change where target=_blank implies rel=noopener. We also imply these, but certainly diverge on scripting behavior.
I've filed a bug with the Chrome project at https://bugs.chromium.org/p/chromium/issues/detail?id=1357515 and have created a test case for sharing at https://freddyb.neocities.org/blank_opener_js_url.html.
I plan to make this bug public if nobody objects in the very near future.
Hi all, I just wanted to check in on the status of this issue. Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1694993 it appears that it may be fixed in 107, the test case no longer executes in that version on Nightly.
I also wanted to ask whether this issue will appear in release notes and if its possible to write a line of attribution?
P.S Very interested to learn why left click blocks execution but middle click executes the javascript!
Thank you!
|
|
||
Comment 10•3 years ago
|
||
I can confirm that this was fixed in bug 1694993.
It looks like the DOM team fixed in an earlier-filed issue and without knowledge of your bug. That makes this here a duplicate and all questions are basically redirected to that other bug.
Regarding the normal-click / middle-click question: A normal click is going through the "navigation" steps in the specification.
Middle-click (or right-click open in new tab) is likely considered a short cut for copy & paste into address bar.
Like copy & paste, this is the user's way to bypass whatever site restrictions there are on a navigation and go to a site.
If you want to ensure that a resource is not using a specific principal, I reckon you have to explore variations of CSP sandbox and <iframe sandbox>.
|
Reporter | |
Comment 11•3 years ago
|
||
Thanks Freddy! Although the duplicate issue was opened two years ago, it does appear to me that the assignee started work on fixing the issue only after reading and commenting on this report. The new information we learnt here was also that this behaviour is present in Firefox version 97 -> 106 by default.
Thanks for your thoughts on the method behind the click madness, I'm keen to investigate further.
Cheers!
Cameron
|
|
||
Comment 12•3 years ago
|
||
@Cameron: Fair enough. Let's ask. :)
@Nika, can you confirm that only comment 5 started you to work on bug 1694993?
I believe this is important for attribution if we write a security advisory.
|
|
||
Comment 14•3 years ago
|
||
Thanks!
|
|
||
Comment 15•3 years ago
|
||
I'm sorry to report that the bounty committee has decided that this does not meet the criteria for a bounty award. This was a specification change that regularized behavior across browsers. The old behavior has risks if misused but was not specifically a vulnerability in Firefox, merely historical browser behavior going back decades.
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
Description
•