search

supabase / auth-js

An isomorphic Javascript library for Supabase Auth.
MIT License
368 stars 165 forks source link

We cannot trust `session.user` on the client side #935

Open j4w8n opened 3 months ago

j4w8n commented 3 months ago

Bug report

Describe the bug

Using data from session.user to render user information is just as insecure on the client side as it is on the server side.

This is because an attacker can signup for an account, login, then change the value of session.user.id in their own cookie, then make a request to the vulnerable app page.

To Reproduce

As with the server side vulnerability, this one also relies on an attacker knowing the Supabase user id of the targeted victim user.

  1. Login to an app
  2. Copy the value of your own auth token
  3. Remove the base64- prefix from the value
  4. Decode the value to get the session
  5. Replace session.user.id with the victim's user id.
  6. Base64 encode the tampered session and prefix it with base64-
  7. Copy the value back into your cookie.
  8. Go to a page that renders sensitive user data based on session.user.id. The victim user's data will be revealed.

Additional Context

https://github.com/orgs/supabase/discussions/23224

retr0cube commented 2 months ago

How can this be mitigated?

j4w8n commented 2 months ago

How can this be mitigated?

The only way I know of, for now, is to call getUser and use the user id from its returned data.

J0 commented 2 months ago

Hey @j4w8n,

Thanks for flagging this again. Agree that this should be guarded against and I think [similar safeguards as described in the earlier thread would apply(https://github.com/orgs/supabase/discussions/23224#discussioncomment-9218731) (e.g. take extra care when using the secret to make verifications so that the attacker can't successfully act on 4 and 5.

  1. Decode the value to get the session
  2. Replace session.user.id with the victim's user id.

We are releasing asymmetric JWTs quite soon though. As with the thread that will likely help since it would take both the public key and the private key to decode, replace, and encode a new payload. The private key would be less likely to be available in this case.

Let us know if there are additional concerns that aren't addressed with asymmetric keys or any immediate pressing concerns