3976: Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener') (on hold) - Composr CMS feature tracker

ID	Project	Category	View Status	Date Submitted	Last Update

3976	Composr	core	public	2019-12-05 03:17	2024-07-30 19:08

Reporter	Adam Edington	Assigned To	Guest
Priority	normal	Severity	feature
Status	new	Resolution	open
Fixed in Version	10.0.29

Summary	3976: Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener') (on hold)
Description	This sounds like a useful and simple protection mechanism which may be worth adding to links.
Additional Information	https://love2dev.com/blog/rel-noopener/
Tags	Type: Security
Attach Tags	(Separate by ",")

Time estimation (hours)	2
Sponsorship open

Date Added	Member	Amount Sponsored

Chris Graham 2019-12-05 16:33 administrator ~6195	Thanks for posting. This is actually a bit of a minefield. On rel="noopener"... rel="noopener" is implemented in browsers for a couple of years only, i.e. is relatively new. We do already support forcing rel="noopener" in Comcode. Normally what happens is a user without 'allow_html' privilege will post something using WYSIWYG, then Composr will convert that HTML to Comcode, and then rel="noopener" will be applied. However, it has increasingly been our policy to greenlight the idea that regular users can be given 'allow_html' privilege and our blacklister in the Comcode compiler would filter out any dangerous HTML like JavaScript (as well as our XSS detector that looks at input). In this scenario, a blacklist is not going to inject additional HTML. Nor should we try to make that happen, Comcode is already incredibly complicated. WHATWG have specified a new policy that target="_blank" links should not have a window.opener to be manipulated: https://github.com/whatwg/html/issues/4078 And browsers have finished implementing it this year: https://bugs.chromium.org/p/chromium/issues/detail?id=927340 https://bugzilla.mozilla.org/show_bug.cgi?id=1503681 https://bugs.webkit.org/show_bug.cgi?id=190481 If a link does not have target="_blank" then there will be no window.opener to manipulate, and no issue. However, a user may put in rel="opener" and workaround this! We could implement blacklisting in the Comcode compiler for rel="opener". Probably as a v10 security fix (I don't think it warrants implementing our security response process though, this is relatively specific and minor). Meanwhile, there is a much more robust approach, a new CSP-like policy COOP: https://www.chromestatus.com/feature/5432089535053824 (this Chrome link provides links to the specification and implementation status in browsers). This is not yet implemented in Chromium, but nearly done. It is already implemented in Firefox. Development has not apparently started in webkit. There is lead time to worry about here. It is a concern that COOP introduces yet another HTTP header for something pretty minor, but it seems worth it. I'd be for implementing this in v11.

Chris Graham 2019-12-05 16:35 administrator ~6196	v10: - Blacklist rel="opener" v11: - Implement COOP ~v12 (once we can rely on COOP being available): - Remove rel="opener" blacklist - Remove rel="noopener" injection in Comcode

Chris Graham 2019-12-06 19:25 administrator ~6204	Implemented changes for v10, and v11. Keeping issue open for ~v12 (with updated title).

Chris Graham 2022-08-15 00:53 administrator ~7446	I've removed the v12 tag as various obscure browsers do not support this (it isn't something implemented by the rendering engine, so even rendering engines using WebKit/Blink are not going to automatically get this). Better to just leave our robust handling in there, for now at least.

View Status	Private (for security issues or disclosing of private information; if you submit as a guest, you will not be able to see your submission)
Note
Upload Files Maximum size: 32,768 KiB	Attach files by dragging & dropping, selecting or pasting them.
You are not logged in	You are not logged in. This means you will not get any e-mail notifications. And if you reply, we will not know for sure you are the original poster of the issue.

Date Modified	Username	Field	Change
2019-12-05 03:17	Adam Edington	New Issue
2019-12-05 03:19	Adam Edington	Description Updated
2019-12-05 15:16	Chris Graham	Tag Attached: Roadmap: v11
2019-12-05 15:16	Chris Graham	Tag Attached: Type: Security
2019-12-05 15:16	Chris Graham	Time estimation (hours)	=> 2
2019-12-05 15:20	Chris Graham	Severity	Feature or Request => Security Hole
2019-12-05 15:20	Chris Graham	View Status	public => private
2019-12-05 16:33	Chris Graham	Note Added: 0006195
2019-12-05 16:35	Chris Graham	Note Added: 0006196
2019-12-05 16:35	Chris Graham	Tag Attached: Roadmap: v12
2019-12-05 16:36	Chris Graham	View Status	private => public
2019-12-06 19:25	Chris Graham	Tag Detached: Roadmap: v11
2019-12-06 19:25	Chris Graham	Note Added: 0006204
2019-12-06 19:27	Chris Graham	Summary	rel='noopener' => Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener')
2022-08-15 00:52	Chris Graham	Tag Detached: Roadmap: v12
2022-08-15 00:53	Chris Graham	Note Added: 0007446
2022-08-15 00:53	Chris Graham	Summary	Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener') => Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener') (on hold)
2024-07-30 19:08	Chris Graham	Severity	Security Hole => Feature or Request