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, when storing a session in cookies and using a framework's server-side rendering feature. In this discussion, I'd like to clarify this topic, from my perspective, and point out some solutions and pitfalls. I welcome your thoughts.

getSession()

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. Everything is working great.

Attack!

For this attack to work, we need to assume the attacker was somehow able to acquire a victim-user's Supabase user id. 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 - not the shown user's id per se, but whatever data you fetched and rendered on the page using that id.

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, but would still return the victim-user's data if you're using session.user.id. 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.

[j4w8n]

@utku-kaan my statement is, in-fact true. The attacker isn't changing any part of the token payload. They're simply logging into a vulnerable app in order to get an access token. That token will bypass a developer's JWT verification - assuming they're using a library like jsonwebtoken to do so. I should've been more clear about how the developer would verify the JWT in this case. I didn't communicate this point well enough, so I'll edit the post a bit. Let me know if it's still coming across differently.

Yes, the getUser method is quick and easy, but not everyone wants an extra network request every time a relevant SSR endpoint is hit.

[GaryAustin1]

So if you use the decoded jwt info you are fine to use the id from that. Just not use the session data itself.

[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.

[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: '42@example.com',
  phone: '',
  app_metadata: { provider: 'github', providers: [ 'github' ] },
  user_metadata: {
    avatar_url: 'https://avatars-r-us.com/u/42',
    email: '42@example.com',
    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
}