Caching menu items between users - Stealing permissions from the last signed in user

[C-monC]

Hi,

This is probably not a bug with superset but I would appreciate help identifying the issue.

When a user logs in they have a small change of getting a frontend that belongs to someone else.
i.e. Clicking profile in the top right menu actually takes you to someone else's profile.

The api always has the correct user ("/api/me/") - there is no data leakage. It just presents broken UI's to users.
The other user's username is also shared with the other user - a big concern.

This issue lasts about a minute. Refreshing the page many times delivers the right page after a while.

The setup:
Superset is running inside an iframe - The purpose of this is because users in the "parent system" have many distinct users in superset.
Nginx is the reverse proxy and Cloudflare is enabled.
I have Security manger class that checks cookies and logs the user in automatically. This worked without issues until about 2 weeks ago.

I have disabled caching completely in Cloudflare and Nginx for the subdomain superset is hosted on with the same results. I can verify in the browser all the requests do not hit caches outside superset.

Are there other caching mechanisms in superset itself?

[msebastiao-maxcapital]

We have the same problem, we started with a fresh installation with the Helm for K8s a few days ago and we thought that the problem was with the OAuth integration with Google, we deactivated it, we tried with users created directly in Superset and the problem persists.
We verified that the error is not only from the profile, the permissions are attached to other logins, and if I am inside with an Alpha role and another user with an Admin role logins, I can see and access all the menus as an Admin. The problem is serious!!!

[C-monC]

I believe the problem is mostly aesthetic - try do requests directly to the API.
Clicking profile with a stolen session takes you to a link that is injected into a template with the g.current_user.email so it does not make an api call. Dirty fix for this - disable viewing of other peoples profiles in config.py.

Could you actually use the stolen permissions to access data? I'm checking this right now.

Please post updates here if you manage to find the source of the issue.

[C-monC]

Okay so I've spent nearly the whole day on this.

There's a bootsrap_data dict that is used by the frontend to configure itself.
Returned by:

return self.render_template(
           "superset/spa.html",
           entry="spa",
           bootstrap_data=json.dumps(
               payload, default=utils.pessimistic_json_iso_dttm_ser
           ),
       )

This is always correctly set in the response. Check response of "/superset/welcome".
div id="app" data-bootstrap="{"user": {"username": "...................

Now even though the bootstrap value is correct in both python and javascript I can still get the frontend for another random user.

Specifically:
const bootstrap = JSON.parse(container?.getAttribute('data-bootstrap') ?? '{}');
const common = { ...bootstrap.common };
const user = { ...bootstrap.user };

user is just ignored.

Considering you also get this issue @msebastiao-maxcapital I think this may be a security vulnerability

[msebastiao-maxcapital]

In the meantime we downgraded to version 2.0.0 and this error does not occur.

It is effectively a security inconvenience, because the users in the frontend happen to have the role of other users.

In the tests we did, it seems that the problem is in the backend, since it seems that the user's session cookie changes when they make a request and another user previously logs in.

[C-monC]

Upgrade to the latest appears to have fixed the issue @msebastiao-maxcapital

Fixed by #21419 (comment) I think

[msebastiao-maxcapital]

Thanks @C-monC, I'll try the latest version then.