Add protection against absence of rel-noopener

[Tori]

Hi,

Shouldn't NoScript protect from this ?
https://mathiasbynens.github.io/rel-noopener/

It doesn't seem very far from XSS, even if it's technically not (or is it ?). Either way, when scripts are enabled, it would be nice that NoScript still protects against such oddities.

I don't even see how this could be a legitimate feature, especially for the cross-origin demo.

[barbaz]

viewtopic.php?f=10&t=21785

[Tori]

Oh, didn't see that. Sorry!

Though the point remains in that NoScript keeps XSS protection enabled even when scripts are globally allowed. Here, if the malicious site has JS enabled, it can apparently do phishing attacks on the other tab. As someone who is very used to NoScript, this is the kind of thing I'd expect it to protect from even with JS enabled, so I was surprised when I tried it out.

This is IMO especially worth considering as a feature when you account for the fact that web browser's protection against this attack involve modifying the website, which ain't going to happen everywhere or soon. A passive protection sounds like it is worth adding to the TODO list. Once upon a time, NoScript could pride itself on implementing fixes right away to newly found exploits, too. That's why I was surprised here.

[barbaz]

Well, I wouldn't go that far, as no one ever answered this -

NoScript does have background tab refresh protections, which should protect against this, right? So does this "attack" still work with NS enabled if it hijacks the original tab actually to a different page, instead of just a different hash on the same page?

[Tori]

In this proof of concept, malicious.html replaces the tab containing index.html with index.html#hax, which displays a hidden message. This is a relatively harmless example, but instead it could’ve redirected to a phishing page, designed to look like the real index.html, asking for login credentials. The user likely wouldn’t notice this, because the focus is on the malicious page in the new window while the redirect happens in the background.

According to the PoC description, that would be a yes.

[Tori]

For the first question in your quote - NoScript doesn't provide protection as long as scripts are allowed on the malicious site.
window.opener is a reference to the previous tab's document or something like that - gives quite a lot of power over it.

[Tori]

Man I'm sorry for the triple post, but here it is laid out in clear:

TL;DR If window.opener is set, a page can trigger a navigation in the opener regardless of security origin.

[barbaz]

OK I looked at what it's doing and put up a test case on my local server. By default, if the attack site's scripts are allowed, NoScript does NOT protect against this attack at all. However, that doesn't mean it can't already do so.

about:config
right-click > new > string
name:

Code: Select all

noscript.surrogate.noopener.replacement

value:

Code: Select all

if(window.opener)window.opener=null;

right-click > new > string
name:

Code: Select all

noscript.surrogate.noopener.sources

value:

Code: Select all

@*

[Tori]

Awesome, it works! I didn't realise surrogates could be used for such built-in functionality as window.opener, but it's obvious now that I see the solution

Will or should NoScript include this by default ?

I wonder if it breaks stuff on the web, that's why I referred to XSS protection, which works with algorithms rather than crude blocking. I'm personally fine with this solution but I use a very strict NS config so I'm not representative.

[barbaz]

Will or should NoScript include this by default ?

No idea. That's up to Giorgio.

I wonder if it breaks stuff on the web,

If it does, create another string pref named

Code: Select all

noscript.surrogate.noopener.exceptions

and add the broken sites to it. Syntax is the same as for ABE rules but without any special tokens.

[Tori]

I'll keep that in mind. Thanks!

[Thrawn]

By default, NoScript does NOT protect against this attack at all.

Except, I assume, when you don't whitelist the target of the link.

[barbaz]

By default, NoScript does NOT protect against this attack at all.

Except, I assume, when you don't whitelist the target of the link.

Yep. I should probably edit that post. Thanks.