Passbolt is not compatible with Firefox Multi-Account Containers

[GotenXiao]

Passbolt is not compatible with Firefox Multi-Account Containers

• Passbolt Version: 1.6.9
• Platform and Target:
  • Browser: Firefox 58.0.2, Windows
  • Web server: Deployed using the passbolt/passbolt Docker image into a Rancher cluster - SSL termination on an haproxy load balancer for cluster ingress traffic
  • etc.: N/A

What you did

When attempting to access a self-hosted Passbolt instance from within a tab container as part of Firefox Multi-Account Containers, authentication succeeds but is not held within the container. By opening a new tab that is not part of any container, the Passbolt interface appears as normal.

What happened

Passbolt is not correctly contained into a container tab.

What you expected to happen

Passbolt is correctly held within a container tab, potentially allowing the use of simultaneous use of different instances that are separated by the tab container context (e.g. work, personal), and preventing the leak of any credentials outside that container (helping to prevent potential theft of credentials from a rogue site).

[stripthis]

Hi @GotenXiao,

I'm not familiar with this other extension, can you provide more details about what you mean by: "Passbolt is not correctly contained into a container tab.". Is it the same as the issue described here: #35

Thanks,

[GotenXiao]

No, I don't think that issue is related.

The container tab extension is part of the Mozilla Contextual Identity Product that aims to be able to separate different browsing contexts into individual security sandboxes (e.g. work, personal, dodgy-site-A) so that tabs opened in each container cannot access resources from other containers.

[stripthis]

@GotenXiao yes I checked the page you linked. I'm just not understanding what you expect to happen with the sentence: "Passbolt is not correctly contained into a container tab."

Passbolt is an extension, not just a webpage, therefore all the buisiness logic such as data storage (e.g. the keyring and user config), the critical operations (encryption, etc.) leaves in a "background page" not the page on the tab itself. See. https://developer.chrome.com/extensions/background_pages or https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension

[stripthis]

@GotenXiao I think what you expect is that there should be one passbolt storage and config running for each of the environment as defined per the information contained in another extension. I'm not saying this can't be done but this not part of the default architecture for web extension.

[Kdecherf]

Hello there,
I'm stuck with this issue too, and I'll try to rephrase the symptom:

I configured my Passbolt account inside a container A. When I try to login to my account inside this container, it always redirects on the login page as if there was no login attempt. When I re-open the site in "No-container" mode the login works.

[dr4Ke]

When we login on the passbolt web page, we expect that the "authorization" cookies or whatever mechanism is used to keep the session open is accessible in the current container (and only this one), so use the current tab cookie store.

It seems that the authentication is shared by both the web page and the plugin, so it affects the plugin too. I guess the plugin has to be aware of "contextualIdentities" to switch to the right cookie store depending on the tab. But then we would have to login on each container we need a password from passbolt. It may not be an issue. And it had the possibility to use different passbolt accounts for different contexts.

[stripthis]

Hello @dr4Ke,

The cookie management is actually handled by the browser itself, as a typical request from the extension looks like this:

const fetchOptions = {
    method: 'POST',
    credentials: 'include',
    body: body
  };
  Request.setCsrfHeader(fetchOptions);
  const response = await fetch(url, fetchOptions);

I'm unsure how/if there is way to alter that behavior without changing the session mechanism (e.g. to avoid using cookies).

[garrettboone]

I just started using containers a month ago...they are really great. Today I noticed as @Kdecherf was sharing, that I could not login to the web page of my Passbolt server, while in a container tab. However, the extension logged in okay, and I was able to use it. Whenever I opened a new link from the extension it opened in a non-container tab, as expected.

So, it's only a half deal breaker. The web side appears to be isolated from the extension. If the plugin could pass to the web something regarding which container it's in, that might give the web the right cookies to look for.

This part from https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers:

An extended origin

An origin is defined as a combination of a scheme, host and port. Browsers make numerous security decisions based off of the origin of a resource using the same-origin-policy. Various features can be re-imagined as simply adding another key to the origin check. These include the Tor Browser’s work on First Party Isolation, Private Browsing Mode, the SubOrigin Proposal, and Containers.

Hence, Gecko has added additional attributes to the origin called OriginAttributes. When trying to determine if two origins are same-origin, Gecko will not only check if they have matching schemes, hosts, and ports, but now also check if all their OriginAttributes match.

Containers adds a userContextId OriginAttribute. Each container has a unique userContextId. Stored site data (like cookies) is now stored with a scheme, host, port, and userContextId. So if a user has example.com cookies for the Shopping userContextId, they will not be accessible by example.com in the Banking Container.

Note that one of the motivations in enabling this feature in Nightly is to help ensure that we iron out any bugs that may exist in our OriginAttribute implementation before features that depend on it are rolled out to users.

[nekromoff]

is it possible for the extension to find out the container ID? Prepending cookies with the container ID / name or other identifier would work for this case without too much effort on developers' side.

Update: Yes, it is possible to work with it once the extensions requests the appropriate permission:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities

There is also an info on using specific identity cookie store ID. This will resolve the issues.

Hello @dr4Ke,

The cookie management is actually handled by the browser itself, as a typical request from the extension looks like this:

const fetchOptions = {
    method: 'POST',
    credentials: 'include',
    body: body
  };
  Request.setCsrfHeader(fetchOptions);
  const response = await fetch(url, fetchOptions);

I'm unsure how/if there is way to alter that behavior without changing the session mechanism (e.g. to avoid using cookies).

[nekromoff]

Any update on the proposed solution?

[stripthis]

I've created a task in our ticketing system to check this. Since this is a firefox only problem, it is on the slow track sorry.

[Benj1er]

Hi @nekromoff,
I checked the solution you proposed, but this change did not solve all the problems.

After further investigation, it seems that Firefox has shared the local storage of the browser extension with all containers and this problem is more complex to solve.

Thanks