[Resolved] Cross-tab identity leak protection

[barbaz]

Bump viewtopic.php?p=106035#p106035 and viewtopic.php?p=106503#p106503

Also, re: NoScript 11.4.23rc2 -

If I test this protection with a cross-site link to this forum while I'm logged in here, and select "Load anonymously", I'm completely logged out of the forum. Is total logout an intended part of the defense? (As opposed to e.g. performing the anonymous load in a new, temporary, NoScript-created Firefox container to prevent logout in the "legitimate" tab, if such is technically possible in WebExtensions.)

That depends on the website. If they automatically assign an anonymous session id (like it happens here), it overrides the one you had and you're automatically logged out for good.
Anyway I'll investigate using containers to mitigate this side effect, thanks.

Looks like NoScript 11.4.23rc2 took a different approach: the anonymous load strips Cookie request headers and Set-Cookie response headers, but preserves the original cookies for subsequent loads.

Which raises a few questions:

1) So cookies are the only thing that needs to be anonymized to fully stop this attack, and the use of Containers for the anonymous load would be overkill?

2) Does it matter that subsequent loads in the tab are not anonymized? e.g. navigating clicking a same-origin link on the anonymously-loaded tab is no longer loaded anonymously

3) Might it matter that cookies in an anonymously-loaded page are still accessible via document.cookie?

Thanks for info

[Giorgio Maone]

At (5), the cross-tab identity leak protection claims that informaction.com can obtain github.com login data at that load, even though the opener tab is github.com. Does the exploit also work through "chaining" opener tabs like this?

Yes, it can. As long as there's one tab in control of the attacker which may know/control the URL of what's loaded in another tab (the oracle site where the user is logged in), the attack is possible.

[Giorgio Maone]

Also, another case I wonder about? -

Firefox 109.0.1
NoScript 11.4.15rc1
new profile

STR:

1) NoScript Options > Advanced, set Cross-tab identity leak protection Enabled everywhere

2) NoScript Options > Per-site Permissions, set github.com and flathub.org to Trusted

3) go to https://flathub.org/

4) middle click any app's listing to open it in new tab

5) in that tab, middle click any link to github.com

6) switch back to the original flathub tab and middle click any other app's listing

This was an artifact of an excessive application of the "chained tabs" checks. It should be (at least in most cases) taken care of by 11.4.23.

[Giorgio Maone]

1) So cookies are the only thing that needs to be anonymized to fully stop this attack, and the use of Containers for the anonymous load would be overkill?

Cookies and the Authorization header. Basically we don't want the user to be logged in on a site loaded in a tab which can be monitored by another site in a different tab.

2) Does it matter that subsequent loads in the tab are not anonymized? e.g. navigating clicking a same-origin link on the anonymously-loaded tab is no longer loaded anonymously

We're assuming the risk is low vs the usability benefit here because:

1. We actually check that the new navigation or reload is user-induced and not automatic, therefore the timing is effectively randomized making the attack much more impractical
2. If the user is in control of the new navigation the scenario of an unintentional / silent attack is much less likely.

3) Might it matter that cookies in an anonymously-loaded page are still accessible via document.cookie?

No, because in practice no website renders massively different (i.e. with differences observable by CPU activity) content and, most of all, identity-dependent, based on document.cookie only.

[barbaz]

Thanks Giorgio for the info & fixes!

At (5), the cross-tab identity leak protection claims that informaction.com can obtain github.com login data at that load, even though the opener tab is github.com. Does the exploit also work through "chaining" opener tabs like this?

Yes, it can. As long as there's one tab in control of the attacker which may know/control the URL of what's loaded in another tab (the oracle site where the user is logged in), the attack is possible.

But in 11.4.23rc4 I no longer get the warning following STR in viewtopic.php?p=106035#p106035 , but you're saying it was correct for the warning to happen there?

[Giorgio Maone]

Thanks Giorgio for the info & fixes!

But in 11.4.23rc4 I no longer get the warning following STR in viewtopic.php?p=106035#p106035 , but you're saying it was correct for the warning to happen there?

11.4.23rc3 and above takes better care of this:

Code: Select all

x [TabGuard] Decouple tab ties cutting from one-shot
  authorized loads cases for same-site navigation

In the case of same-site manual navigation to secondary tabs (like this), previous versions both kept the ties alive and stripped the cookies away. The latter measure was unnecessary, since the risk we want to prevent here is the same-site navigation in a new tab being just a redirection to an actual cross-site "victim" site (in this case, github.com being the attacker and another site being the potential victim).

On a side note, Github doesn't play very well with the latest usability improvements: in fact, same-site same-tab navigation cannot automatically trigger authorization reinstatement, because when JavaScript is enabled it all happens client side. You either need to manually reload or, like you did here, use middle-click which does cause an actual "organic" navigation.

[barbaz]

The latter measure was unnecessary, since the risk we want to prevent here is the same-site navigation in a new tab being just a redirection to an actual cross-site "victim" site (in this case, github.com being the attacker and another site being the potential victim).

Ah ok, so in those specific STR, the protection was indeed overzealous - it didn't need to trip for that site pair unless the github page in the "chained" opener tab were to redirect back to informaction.

Appreciate the elucidation Giorgio, I think all my questions in this thread are now resolved