SSR attack vector, and mitigation, when using session from getSession()

[j4w8n]

As briefly described on PR supabase/auth-helpers#722, an attacker can retrieve sensitive user data through an attack vector within auth-js and a developer's code. This attack is based on a developer:

• storing user sessions in cookies
• using server-side rendering
• retrieving users' data via information within session.user

In this discussion, I'd like to clarify the topic, from my perspective, and point out some solutions and pitfalls. I welcome your thoughts.

To summarize:

• It is unsafe to call getSession() on the server and then use unique data like session.user.id, to return that user's sensitive information.
• It is safe to call getSession() to retrieve a user's tokens (access, refresh).
• Using non-unique, or non-sensitive, information returned by getSession() is likely safe, but be cautious - e.g. a public url for their avatar, via session.user.user_metadata.avatar_url in the case of a GitHub OAuth login. Just keep in mind that accessing session.user currently throws a console warning.

getSession() vulernability

If we look at how this method works, we see that it runs minimal checks on the potential session it grabs from storage. When I say "minimal checks", I'm not casting any blame; Supabase can't do much more than what it already is.

1. Checks if the session is null.
2. Further validates the session by ensuring that it's of type object, and that it has the properties access_token, refresh_token, and expires_at.
3. Finally, if expires_at is some point in the future, it returns the session to you.

This seems reasonable, but if we craft a cookie with the following values, it would pass all of those checks:

{
  access_token: '',
  refresh_token: '',
  expires_at: '3000000000'
}

Developer code

Say you're server-side rendering a user's page that's been requested. You check that the user is logged-in by calling getSession() - perhaps in middleware. Data from that call comes back to you, so it seems we have an authenticated user for this request. So, now you fetch the user's sensitive data based on the value of session.user.id, then the page contents are returned and rendered in the browser.

It's worth noting that if you're creating a typical Supabase client that's been authenticated with the user's access_token, you're likely not going to fall victim here. This is because any db calls are going to be using that access token against your RLS policies - assuming you use something like auth.uid(). Even if you were to have a request like .eq('user_id', session.user.id), it would fail RLS and no data would be rendered; because the access token's user won't have permissions for any table rows for your victim-user's id.

I'd say the most likely scenario for an attack would be if you're using a "service role" client, or other Supabase client which has elevated db permissions or can bypass RLS (or possibly an RPC call). Because in this scenario, you might craft code similar to:

const { data, error } = await supabaseServiceClient.from('table').select('*').eq('user_id', session.user.id)

In which case...

Attack!

For this attack to work, we need to assume the attacker was able to acquire a victim-user's Supabase user id. It also requires knowledge of the cookie name for user sessions, but this is trivial to find. We also assume the attacker does not have the user's access token or refresh token - otherwise they could just use those to get the victim's data.

Now imagine the attacker sends a page request to the server, using a properly-named cookie with this data:

{
  access_token: 'got',
  refresh_token: 'ya',
  expires_at: '3000000000',
  user: {
    id: '<victim-user-id>'
  }
}

Oh snap! All of the getSession() checks have passed and you've now sent the victim-user's sensitive data back to the attacker.

Mitigation

!!!!!

Only use your JWT secret on the server-side, and only via a private env var. If there are other secure methods, I don't know what they are.

!!!!!

Here are a few things we can do to prevent this attack.

1. Don't use anything from session to render sensitive data. The only exception is verifying and decoding the access_token, with a library such as jsonwebtoken, and then use information within the decoded JWT to load sensitive user data. So, from our example, instead of using session.user.id, grab the value of the sub property from a verified and decoded JWT - which is the user id of whoever the JWT was created for.
2. As the Supabase docs currently recommend: call getUser() to retrieve the user's data and use it to fetch further data for the page. Yes, the getUser call grabs the access_token from getSession and verifies it, but it's worth mentioning that you still can't trust anything else from the session info returned by getSession(). Anyway, if step 1 is not feasible or desired, calling getUser is the easiest solution. The downside is that it requires an extra network request every time you call it - either to Supabase's cloud instance or your self-hosted Supabase instance.

False Security

When I came across this attack vector, my natural solution was to simply call getSession() and verify the JWT, aka session.access_token. I assumed that as long as the JWT checks out, I can use data within session.user to render the page.

However, after thinking about it more, I realized this is a mistake. To understand why, imagine an attacker signs up for an actual account with your app and signs-in. They can then take their legit access token and send a separate request with the below cookie data:

{
  access_token: '<attackers-legit-access-token>',
  refresh_token: 'still got ya',
  expires_at: '3000000000',
  user: {
    id: '<victim-user-id>'
  }
}

As you can see, this would pass the getSession() checks and your JWT verification (access_token), but would still return the victim-user's data. So don't assume everything inside of session can be trusted just because you were able to verify the access_token.

If, instead, we were to grab the legit attacker's token and use the decoded JWT info from it, this would render the attacker's data instead of the would-be victim's. Just take precautions to only use your project's JWT secret, to verify/decode, on the server-side.

[vickkhera]

Nice explanation. I was just looking at some code and I do a setSession() call after validating the token. That would seem to be the right place to make sure the session was replaced with the claims from the token. I need to look to see if that actually happens.

[j4w8n]

Nice explanation. I was just looking at some code and I do a setSession() call after validating the token. That would seem to be the right place to make sure the session was replaced with the claims from the token. I need to look to see if that actually happens.

@vickkhera yes, that would mitigate it as well. setSession calls getUser under-the-hood, and then saves a subset of data to session, including user data from the getUser call. So if it's just the user data you're after, calling getUser() will suffice. But if you're also wanting to essentially authenticate the Supabase client based on the access token, then setSession() is the way to go. Just be aware that with setSession, the saved session will only have the below properties:

/* Reference: https://github.com/supabase/auth-js/blob/master/src/GoTrueClient.ts#L1328-L1334 */
{
  access_token, /* Whatever was passed-in to setSession() */
  refresh_token, /* Whatever was passed-in to setSession() */
  user, /* Based on the getUser() call */
  token_type, /* Always "bearer" */
  expires_at, /* Calculated from the decoded access_token */
  expires_in /* From the decoded access_token */
}

[vickkhera]

Hrm... I was trying to save myself a round-trip to the DB but I guess there's just no way to do that. I'll just change to using the sub properties from the JWT I validated the few places I need it.

[utku-kaan]

Thank you for writing this, it's really helpful.

However, after thinking on it more, I realized this is a mistake. To understand why, imagine an attacker signs up for an actual account with your app and signs-in. They can then take their legit access token and send a separate request with the below cookie data:

This isn't true. I was really surprised at this. I'd thought that getSession would decode the JWT payload and use that to construct the user object, but like you mention, it just reads it directly from the cookie with no validation.

[utku-kaan]

@j4w8n I apologize, it's my mistake. I assumed that getSession wouldn't just blindly read from the cookie. I naively assumed that it'd decode the JWT payload and use that to construct the user object instead, but it turns out that it just reads directly from the cookie to save a network request.

Yes, the getUser method is quick and easy.

Sadly, even the getUser() function doesn't protect you from this attack if you use the session returned from getSession. It still returns possibly altered cookie data. Since there's no check, the client can modify the cookie however they want, and it will still blindly return that data both on the server and the client.

At this point, I'd recommend renaming getSession to getSessionFromCookie to make it clear that it's not doing any validation. Thank you for bringing this to my attention. I'll update the post to clarify this point and provide a more secure example.

[j4w8n]

Sadly, even the getUser() function doesn't protect you from this attack if you use the session returned from getSession. It still returns possibly altered cookie data. Since there's no check, the client can modify the cookie however they want, and it will still blindly return that data both on the server and the client.

@utku-kaan you're exactly right here. I just added some verbiage within mitigation 2, to emphasize this.

[jacktsin1]

@j4w8n thanks for the analysis! What if you use .getSession() in combination with RLS as described here?

[j4w8n]

@j4w8n thanks for the analysis! What if you use .getSession() in combination with RLS as described here?

@jacktsin1 I'm not familiar enough with Next to speak on it. But as long as you aren't using info within session.user to render users' data, then this attack isn't relevant.

I've just updated my post, to include some example calls and emphasize that this is more geared towards Supabase clients with elevated db privileges. If someone disagrees, let me know.

[jacktsin1]

@j4w8n Thanks, I suppose the approach I described will do the trick for the majority who don't want to compromise on performance.

In the case I described Nextjs's middleware is just an extra layer of "auth" but the real security functionality basically depends on RLS (not on getUser() or getSession() which are executed in the app — RLS runs directly in your DB when a request reaches it).

If RLS is secure/not vulnerable, then this approach should also be secure.

Either way, if RLS is not in place, I'm not sure if an attacker needs to go through your app to query your DB instance if they have your Public Connection string / Anon key (they are usually publicly available if an app is at least using client-side Auth or Real-Time, not to mention client-side data fetching/mutations).

In fact, even if you have RLS in place, an attacker can still make as many requests as they want to your instance potentially exhausting your bandwidth (given that your connection string and anon key are used client-side), they just won't be able to obtain or alter sensitive information that are being protected by RLS.

So I assume getSession() vs getUser() is just a small portion of the existing vulnerabilities when it comes to how someone could harm your app and data.

And what I mean basically is that if you don't expose your anon key and connection string to the client (which might be a challenge if you need to use Real-Time and client-side Auth), and have RLS in place, it won't really matter if you use getSession() instead of getUser() since your DB and data will be secure either way.

Vice versa, if you expose your anon key and connection string, and don't have RLS in place, then it still won't make much of a difference if you use getUser() or getSession() since the attacker will have to perform a very specific form of attack to get blocked while your DB will be vulnerable to everything else (again, please correct me if I'm wrong at any part).

[hf]

Thank you for this explanation @j4w8n.

The team is actively working on new features within auth-js that makes it easier to verify the JWT (access token) soon. This should alleviate some of the problems with latency if you rely on getUser() for it. Until that's out, proceed with caution on verifying the access token yourselves -- it can be very easy to leak your JWT signing secret. For example, do not:

• Do not put it in environment variables that become public, like those prefixed NEXT_PUBLIC
• Do not put it in a constant, e.g. const myJwtSecret -- this can accidentally end up in your public source code

A leaked JWT secret opens up not only your users under attack (as they can be easily impersonated) but more severely your database (the secret can be used to mint your own JWTs with any role that can bypass RLS).

[GaryAustin1]

This seems like about the same risk as using service_role leaking. Am missing something? The JWT is only used for the API so you can't execute SQL or be a user not assigned to Authenticator. I guess you could isolate a function in one place to reduce the chance of it getting out in wrong kind of client.

[SebasScript]

@j4w8n I have a simple question on this.

Oh snap! All of the getSession() checks have passed and you've now sent the victim-user's sensitive data back to the attacker - not the shown user's id per se, but whatever data you fetched and rendered on the page using that id.

Is this only an issue though if there are "trusted" operations performed server side or server component side?
Means i get information from supabase by using a service role key for example?

If one performs queries for example in a server component and implements @supabase/ssr the mal formed attacker cookie would be passed to the server side supabase instance for example in a middleware in next.js or passed to an edgefunction that generate a server based client with it.

For the middle ware In the old version in of the supabase docs (from a couple weeks ago) this still used
supabase.auth.getSession();
which has now been updated to getUser().

If we stick to the old version

const supabase = createServerClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
  {
    cookies: {
      get(name: string) {
        return request.cookies.get(name)?.value;
      },
      set(name: string, value: string, options: CookieOptions) {
        request.cookies.set({
          name,
          value,
          ...options,
        });
        response = NextResponse.next({
          request: {
            headers: request.headers,
          },
        });
        response.cookies.set({
          name,
          value,
          ...options,
        });
      },
      remove(name: string, options: CookieOptions) {
        request.cookies.set({
          name,
          value: "",
          ...options,
        });
        response = NextResponse.next({
          request: {
            headers: request.headers,
          },
        });
        response.cookies.set({
          name,
          value: "",
          ...options,
        });
      },
    },
  }
);

await supabase.auth.getSession();

return response;
}

in an edge function same by reading the auth header from the request and passing that into the create client

   const authHeader = ctx.request.headers.get("Authorization"); //using oak here to get the auth header
  const supabaseClient = createClient<Database>(
    Deno.env.get("SUPABASE_URL") ?? "",
    Deno.env.get("SUPABASE_ANON_KEY") ?? "",
    {
      auth: {
        persistSession: false,
      },
      global: {
        headers: {
          Authorization: authHeader || "",
        },
      },
    }
  );

this would use the mal formed cookie now and not verify it. But if one now performs a database query with this mal formed supabase client the query should fail on the backend as the backend would try to validate the malformed jwt that is send with the request?

[j4w8n]

@SebasScript, you're typically fine with db queries like the ones you mentioned, because only the access_token is used.

The exception to that is using a Supabase client on the server-side with elevated privileges, like the service_role key that can bypass RLS, and using filters based on data from session.

For example, the below would return a victim-user's data.

/* Received attacker request with this cookie: */
{
  access_token: 'got',
  refresh_token: 'ya',
  expires_at: '3000000000',
  user: {
    id: '<victim-user-id>'
  }
}

const supabaseServiceClient = "code here" /* Construct with `service_role` key. */
const { data: session } = await supabaseServiceClient.auth.getSession()

const { data, error} = await supabaseServiceClient.from('table').select('*').eq('user_id', session.user.id)

[chanon]

Can I ask, other than sub, which I assume is the user's uuid, what other data can be guaranteed to be available in the decoded access_token JWT ?

[j4w8n]

Here is a cleaned version of a decoded JWT, when logging in with GitHub. Yes, sub is the user's ID.

{
  aud: 'authenticated',
  exp: 1714645059,
  iat: 1714644819,
  iss: 'https://<project-id>.supabase.co/auth/v1',
  sub: '00000000-0000-0000-0000-000000000000',
  email: '[email protected]',
  phone: '',
  app_metadata: { provider: 'github', providers: [ 'github' ] },
  user_metadata: {
    avatar_url: 'https://avatars-r-us.com/u/42',
    email: '[email protected]',
    email_verified: true,
    full_name: 'Forty Two',
    iss: 'https://api.github.com',
    name: 'Forty Two',
    phone_verified: false,
    preferred_username: 'fortytwo',
    provider_id: '25783093',
    provider_token: '',
    sub: '00000000',
    user_name: 'fortytwo'
  },
  role: 'authenticated',
  aal: 'aal1',
  amr: [ { method: 'oauth', timestamp: 1714643412 } ],
  session_id: '11111111-1111-1111-1111-111111111111',
  is_anonymous: false
}

[godlin-gh]

I am trying to build my app with Next.js and Supabase Auth following this doc: https://supabase.com/docs/guides/auth/server-side/nextjs

Now the doc says we should use getUser() in the Next.js middleware, and it sends a request to the Supabase Auth server every time to revalidate the Auth token.

But The Next.js middleware runs on edge runtime, which is close to end users but may be farway from Supabase Auth server

Then, the getUser() may experience significant latency depending on the user's location.

In my case, the latency is more than 500ms，from HongKong to the US.

Middleware is not designed for direct data fetching or manipulation, this should be done within Route Handlers or server-side utilities instead. https://nextjs.org/docs/pages/building-your-application/routing/middleware#use-cases

I hope you guys can solve this problem as soon as possible, may be you can issue a signed idToken and read user profile from it.

[bbozzay]

I implemented the new getSafeSession changes in my project and had no indication locally that there would be a massive spike in redundant auth requests caused by this. Once I deployed, I eventually noticed a huge spike and thought I was getting DDoS'd...

I immediately jumped from <100 auth requests per hour to around 1-3k per hour.

My project uses Sveltekit, but I noticed @Zanzofily next.js safesession package created to address the performance problems as well. He notes that one user generated 1,685 calls.

I implemented this change based on the official docs. I imagine this issue is widespread, but I'm still seeing stale Git issues from back in March. I created a reddit thread for more visibility. Now I'm scrambling to implement the changes based on your sveltekit-supabase-ssr project.

[Zanzofily]

I implemented the new getSafeSession changes in my project and had no indication locally that there would be a massive spike in redundant auth requests caused by this. Once I deployed, I eventually noticed a huge spike and thought I was getting DDoS'd...

I immediately jumped from <100 auth requests per hour to around 1-3k per hour.

My project uses Sveltekit, but I noticed @Zanzofily next.js safesession package created to address the performance problems as well. He notes that one user generated 1,685 calls.

I implemented this change based on the official docs. I imagine this issue is widespread, but I'm still seeing stale Git issues from back in March. I created a reddit thread for more visibility. Now I'm scrambling to implement the changes based on your sveltekit-supabase-ssr project.

Fixing this issue is relatively simple. A single solution can be applied to the TuroAuthClient and would serve all frameworks.

I believe the reason this might be taking a while is the uncertainty that everyone would follow best practices (validate session using database on the middleware or every now and then, using the right database constraints on user_id, and preventing insertions/updates from a deleted user)

If you implement the solution in my or @j4w8n repo, make sure you keep an eye open for these cases.

[DawidWraga]

Thank you for highlighting this issue

This is a very important and urgent problem that Supabase team must prioritise to keep the trust of developers

I really hope to see the Supabase team addressing this quickly otherwise I feel forced to consider alternatives, which I really don't want to do

[Aradon267]

Amazing article!
Is it fine to use the "data" from getSession(data=wether or no I received something) only to know if the user is connected and to do all the other things that are related to data fetching(like getting the user id to get its data from the DB) using the getUser?

Edit:
The basic code that I mean to see if the user is logged in is

//supabase middleware creation

const { data: activatedUser, error } = await supabase.auth.getSession();
    return NextResponse.rewrite(new URL("/login", request.url));
  }

  return response;

While any other request I make using the user's actual data(i.e. the user's ID) is always received using getUser

Also due to the getSession that is used(although no data is used to fetch anything) - I get the log that it's unsafe to use that which is fair as it is but calling getUser for each server action that is used in the client(they all go through my middleware) seems extensive as I also have RLS setup and most of the time for me calling getUser causes rate limits

[Aradon267]

And would that still be the case if it's combined with the first mitigation proposed?

[j4w8n]

No, that's not the case if you're doing mitigation number 1. You'd be good to go as long as you're checking event.locals.getSession and not supabase.auth.getSession

[Aradon267]

And is there a reason for any method to not work in either place? I can understand why the first is bad on the client because I don't want to leak the JWT but is there a reason for the getUser to not work on the server side(just something that I only now started dealing with as it says there's no session)?

[j4w8n]

And is there a reason for any method to not work in either place? I can understand why the first is bad on the client because I don't want to leak the JWT but is there a reason for the getUser to not work on the server side(just something that I only now started dealing with as it says there's no session)?

You might be dealing with a different issue in that case, because getUser works on client side and server side.

[Aradon267]

Yeah that worked for a long time, will try to see the problem
Thanks!