Honestly I've never heard of it being a security risk any more than a normal href. It's NO different than middle clicking or ctrl-click in terms of mechanism of action.
You don't really say HOW it's actually a security issue. Literally if it is, then the entire way I normally navigate index pages on websites would be since I middle click a lot. No, A LOT.
This claim makes zero sense. I'm going to have to test this, it should not be triggering any event that isn't triggered on normal navigation. If that's true, that's horrifyingly bad.
That said, there is a perfectly legitimate reason to not set target="_blank", and it's why it was invalid in 4 Strict. It's usability and accessibility garbage breaking normal forward/back navigation and removing user choice. The user wants it iin a new window, they can middle click, ctrl+click, etc, etc. Don't shove new windows down the user's gullet!
As I said, "I'm going to have to test this" -- and I just did, and it doesn't do what's claimed in Vivaldi or Firefox. Did some research and this security hole was apparently plugged years ago.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
In the case that article outlines, at least for me in FF, Vivaldi, and Chrome (Winblows 10 and Linsux) window.opener is NULL meaning that code doesn't work. Their codeSandbox example throwing the following error:
TypeError
Cannot set properties of null (setting 'location')
HTMLAnchorElement.link.onclick
window.opener is null, As such they're only infecting two things. And Jack left town.
Technically if you open with _blank anyways unless you set rel="opener", there shouldn't be window.opener available on the resulting page either nor should it impact http_referer. As per what MDN says on it:
Windows opened because of links with a target of _blank don't get an opener, unless explicitly requested with rel=opener.
They also suggest setting Cross-Origin-Opener-Policy to same-origin in your CSP, which is good advice if you really care about it and are using the middle finger to accessibility.
As such the only people likely to get infected by it are those who don't update their browsers, in which case there are hundreds if not thousands of vulnerabilities they're open to, and they get what's coming to them.
There are multiple valid reasons to open a link in a new tab, the most compelling one of them being that you are inside a web app and the user expect links to open in a new tab.
And no, a wish for user retention is not a valid reason.
I could see that if the point is to open it in a browser when in a "native" app such as running under Electron. If it's web facing in the browser? Not so much.
The problem is far too many developers throw it at everything, just BEGGING to get their tuchas sued off for WCAG violations given the middle finger it is to users on screen readers, braille readers, etc, etc.
But then that's my bread and butter, helping website owners who are in court for accessibility failings under laws like the US ADA, UK EQA, etc, etc. Thus why 90% of my job is instructing client's development teams in ripping out every last dumbass HTML/CSS framework, shredding anything remotely resembling CSR unless it absolutely positively cannot be done without, and taking a sledgehammer to garbage like target="_blank", pixel metric fonts/layout, illegible colour contrasts, and endless idiotic "DIV soup".
Like the client (public utility) I just helped who had this issue, alongside a broken inaccessible train wreck of angular that made it impossible for around a quarter of clients to even pay their bills online. Said site now rewritten from using 2 megabytes of "JS for nothing" and broken HTML, to a site that doesn't even use JavaScript, has 1/8th the markup, and not an accessibility violation in sight. They were shoving new windows down the users gullet too, to the point that when (if) their idiotic CSR trash worked, just logging in to "pay your bill" opened four freaking tabs! ON THE SAME SITE!!!
That's some serious hurr durrz ermagahd aherpaderp right there.
Newsflash: you can run most electron apps that don't require node APIs directly in the browser. You can even install these web apps locally on most modern operating systems. And it's totally ok not to open a link in the same window in which a chat or a WebRTC meeting is currently open.
Yes, I get your point that target _blank is overused, but that doesn't make its use generally invalid inside the browser window. The main difference is the developer asking if target _blank actually improves the user experience and only uses it if the answer is "absolutely yes".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Honestly I've never heard of it being a security risk any more than a normal href. It's NO different than middle clicking or ctrl-click in terms of mechanism of action.
You don't really say HOW it's actually a security issue. Literally if it is, then the entire way I normally navigate index pages on websites would be since I middle click a lot. No, A LOT.
This claim makes zero sense. I'm going to have to test this, it should not be triggering any event that isn't triggered on normal navigation. If that's true, that's horrifyingly bad.
That said, there is a perfectly legitimate reason to not set target="_blank", and it's why it was invalid in 4 Strict. It's usability and accessibility garbage breaking normal forward/back navigation and removing user choice. The user wants it iin a new window, they can middle click, ctrl+click, etc, etc. Don't shove new windows down the user's gullet!
@deathshadow60 No hard feelings, Have you ever tried to exploit this way?
As I said, "I'm going to have to test this" -- and I just did, and it doesn't do what's claimed in Vivaldi or Firefox. Did some research and this security hole was apparently plugged years ago.
It's been plugged, but realize there are people who haven't updated their browsers since years ago.
"what" has been fixed exactly?
Isn't this still a potential attack vector?
thecodest.co/blog/web-app-security...
In the case that article outlines, at least for me in FF, Vivaldi, and Chrome (Winblows 10 and Linsux) window.opener is NULL meaning that code doesn't work. Their codeSandbox example throwing the following error:
window.opener is null, As such they're only infecting two things. And Jack left town.
Technically if you open with _blank anyways unless you set rel="opener", there shouldn't be window.opener available on the resulting page either nor should it impact http_referer. As per what MDN says on it:
developer.mozilla.org/en-US/docs/W...
and I quote:
They also suggest setting Cross-Origin-Opener-Policy to same-origin in your CSP, which is good advice if you really care about it and are using the middle finger to accessibility.
As such the only people likely to get infected by it are those who don't update their browsers, in which case there are hundreds if not thousands of vulnerabilities they're open to, and they get what's coming to them.
There are multiple valid reasons to open a link in a new tab, the most compelling one of them being that you are inside a web app and the user expect links to open in a new tab.
And no, a wish for user retention is not a valid reason.
I could see that if the point is to open it in a browser when in a "native" app such as running under Electron. If it's web facing in the browser? Not so much.
The problem is far too many developers throw it at everything, just BEGGING to get their tuchas sued off for WCAG violations given the middle finger it is to users on screen readers, braille readers, etc, etc.
But then that's my bread and butter, helping website owners who are in court for accessibility failings under laws like the US ADA, UK EQA, etc, etc. Thus why 90% of my job is instructing client's development teams in ripping out every last dumbass HTML/CSS framework, shredding anything remotely resembling CSR unless it absolutely positively cannot be done without, and taking a sledgehammer to garbage like target="_blank", pixel metric fonts/layout, illegible colour contrasts, and endless idiotic "DIV soup".
Like the client (public utility) I just helped who had this issue, alongside a broken inaccessible train wreck of angular that made it impossible for around a quarter of clients to even pay their bills online. Said site now rewritten from using 2 megabytes of "JS for nothing" and broken HTML, to a site that doesn't even use JavaScript, has 1/8th the markup, and not an accessibility violation in sight. They were shoving new windows down the users gullet too, to the point that when (if) their idiotic CSR trash worked, just logging in to "pay your bill" opened four freaking tabs! ON THE SAME SITE!!!
That's some serious hurr durrz ermagahd aherpaderp right there.
Newsflash: you can run most electron apps that don't require node APIs directly in the browser. You can even install these web apps locally on most modern operating systems. And it's totally ok not to open a link in the same window in which a chat or a WebRTC meeting is currently open.
Yes, I get your point that target _blank is overused, but that doesn't make its use generally invalid inside the browser window. The main difference is the developer asking if target _blank actually improves the user experience and only uses it if the answer is "absolutely yes".