View Issue Details

IDProjectCategoryView StatusLast Update
0003976Composrcorepublic2019-12-06 19:27
ReporterAdamAssigned To 
Status non-assignedResolutionopen 
Product Version 
Fixed in Version10.0.29 
Summary0003976: Remove rel-noopener and rel-opener spec reference in favour of pure-COOP (WAS: rel='noopener')
DescriptionThis sounds like a useful and simple protection mechanism which may be worth adding to links.
Additional Information
TagsRoadmap: v12, Type: Security
Attach Tags
Time estimation (hours)2
Sponsorship open


Chris Graham

2019-12-05 16:33

administrator   ~0006195

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:
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.

Chris Graham

2019-12-05 16:35

administrator   ~0006196

 - Blacklist rel="opener"

 - 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   ~0006204

Implemented changes for v10, and v11. Keeping issue open for ~v12 (with updated title).

Issue History

Date Modified Username Field Change
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')