Change Details

Introduced in [[ https://www.mediawiki.org/wiki/Special:Code/MediaWiki/41333 | r41333 ]], `$wgExternalLinkTarget` allows MediaWiki operators to set the target attribute on external links. The documented use-case is to set `$wgExternalLinkTarget = '_blank';`, so links open in a new window or tab: ```lang=php, name=includes/DefaultSettings.php L4205-4208 /** * Set a default target for external links, e.g. _blank to pop up a new window */ $wgExternalLinkTarget = false; ``` The problem is that when you click on a target="_blank" link, JavaScript code on the destination page has full control of the window object of the source page, via `window.opener`. This is true regardless of security origin. `window.opener.document` is protected by CORS, but `window.opener.location` is not, allowing the target page to surreptitiously redirect the tab that opened it to a phishing page. There is a good explanation of this issue, with working examples, at https://mathiasbynens.github.io/rel-noopener/ This is a good reason never to use target="_blank" with user-generated links. Should we prevent users from shooting themselves in the foot by deprecating and refusing to honor `$wgExternalLinkTarget` when it is set to "_blank"? ([[ https://css-tricks.com/use-target_blank/ | This article ]] suggests most people who think they want to use _blank shouldn't.) At minimum, I think we should: * Update the comment to make it clear that this is risky. * Emit a warning when the configured value is unsafe.

Introduced in [[ https://www.mediawiki.org/wiki/Special:Code/MediaWiki/41333 | r41333 ]], `$wgExternalLinkTarget` allows MediaWiki operators to set the target attribute on external links. The documented use-case is to set `$wgExternalLinkTarget = '_blank';`, so links open in a new window or tab: ```lang=php, name=includes/DefaultSettings.php L4205-4208 /** * Set a default target for external links, e.g. _blank to pop up a new window */ $wgExternalLinkTarget = false; ``` The problem is that when you click on a target="_blank" link, JavaScript code on the destination page has full control of the window object of the source page, via `window.opener`. In the event the page is cross-origin, the new window is allowed to set window.opener.location to a new value. `window.opener.document` is protected by CORS, but `window.opener.location` is not, allowing the target page to surreptitiously redirect the tab that opened it to a phishing page. There is a good explanation of this issue, with working examples, at https://mathiasbynens.github.io/rel-noopener/ This is a good reason never to use target="_blank" with user-generated links. Should we prevent users from shooting themselves in the foot by deprecating and refusing to honor `$wgExternalLinkTarget` when it is set to "_blank"? ([[ https://css-tricks.com/use-target_blank/ | This article ]] suggests most people who think they want to use _blank shouldn't.) At minimum, I think we should: * Update the comment to make it clear that this is risky. * Emit a warning when the configured value is unsafe.

Introduced in [[ https://www.mediawiki.org/wiki/Special:Code/MediaWiki/41333 | r41333 ]], `$wgExternalLinkTarget` allows MediaWiki operators to set the target attribute on external links. The documented use-case is to set `$wgExternalLinkTarget = '_blank';`, so links open in a new window or tab: ```lang=php, name=includes/DefaultSettings.php L4205-4208 /** * Set a default target for external links, e.g. _blank to pop up a new window */ $wgExternalLinkTarget = false; ``` The problem is that when you click on a target="_blank" link, JavaScript code on the destination page has full control of the window object of the source page, via `window.opener`. This is true regardless of security originIn the event the page is cross-origin, the new window is allowed to set window.opener.location to a new value. `window.opener.document` is protected by CORS, but `window.opener.location` is not, allowing the target page to surreptitiously redirect the tab that opened it to a phishing page. There is a good explanation of this issue, with working examples, at https://mathiasbynens.github.io/rel-noopener/ This is a good reason never to use target="_blank" with user-generated links. Should we prevent users from shooting themselves in the foot by deprecating and refusing to honor `$wgExternalLinkTarget` when it is set to "_blank"? ([[ https://css-tricks.com/use-target_blank/ | This article ]] suggests most people who think they want to use _blank shouldn't.) At minimum, I think we should: * Update the comment to make it clear that this is risky. * Emit a warning when the configured value is unsafe.