View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003976||Composr||core||public||2019-12-05 03:17||2019-12-06 19:27|
|Fixed in Version||10.0.29|
|Summary||0003976: Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener')|
|Description||This sounds like a useful and simple protection mechanism which may be worth adding to links.|
|Tags||Roadmap: v12, Type: Security|
|Time estimation (hours)||2|
Thanks for posting.
This is actually a bit of a minefield.
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.
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:
And browsers have finished implementing it this year:
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:
(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.
- Blacklist rel="opener"
- Implement COOP
~v12 (once we can rely on COOP being available):
- Remove rel="opener" blacklist
- Remove rel="noopener" injection in Comcode
||Implemented changes for v10, and v11. Keeping issue open for ~v12 (with updated title).|
|2019-12-05 03:17||Adam||New Issue|
|2019-12-05 03:19||Adam||Description Updated||View Revisions|
|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 => 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')|