Need ability to consume appcheck token in auth blocking functions

[jostster]

Related issues

[REQUIRED] Version info

node: 16

firebase-functions: ^4.4.1

firebase-tools: ^9.14.0

firebase-admin: ^11.7.0

[REQUIRED] Test case

N/A

[REQUIRED] Steps to reproduce

In your browser open network inspector from developer console. Login to your application Select the signInWithPassword item from the network inspector and copy as cURL. Edit the username / password from the curl command to another user and password and run the curl command. AppCheck token can be reused when hitting the firebase API directly with the public facing key

[REQUIRED] Expected behavior

Firebase auth needs a way to expire appcheck tokens to prevent abusers from hitting the API directly and reusing the same appcheck token

[REQUIRED] Actual behavior

Abusers can hit the firebase sdk api's directly and bypass any appcheck by reusing the same appcheck token which is valid for 30 minutes.

Were you able to successfully deploy your functions?

Yes.

There isn't access to the request object in firebase auth blocking functions so it makes consuming the appcheck token impossible. The request object should be added to the auth blocking function or support for consuming the appcheck token for auth blocking should be added to prevent abuse.

A similar ticket was created and closed with mentioning to use the admin sdk to consume the app check token. I do not see how this can be done when abusers hit the api endpoint directly.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[blidd-google]

Hi @jostster, today we do not have plans to officially support verifying and consuming app check tokens in auth blocking functions. Given that auth blocking functions are only intended to be triggered by the Google Cloud Identity Platform backend, we don't see a strong use case for app check for these function types. Alternatively, we are reaching out to the GCIP team to see if we can make auth blocking functions private so that the endpoints are not exposed publicly, which should close off some of the abuse vectors you've described.

However, if you'd like, it is possible to implement logic that will verify and consume app check tokens. You can use https://github.com/firebase/firebase-functions/blob/3e7a4b77967e46a067712445c499c5df005b8e31/src/common/providers/https.ts#L631 as a guide. I'm going to go ahead and close this issue for now, but please keep an eye out for updates about future security improvements.

[jostster]

@blidd-google Thanks for the response. However, could you advise on how we would consume app check tokens in auth blocking functions since we don't have access to the request object in the auth blocking functions?

[Boardtale]

@blidd-google "Given that auth blocking functions are only intended to be triggered by the Google Cloud Identity Platform backend" how is that if such function has to be http public? I wasn't able to find a way to set any Service Account function.invoker - there's none, for this to be true.

[geekbleek]

FYI @Boardtale the function doesn't have to be http public - it has to be unauthenticated because the triggered event comes from GCIP. You can set network access to internal only.