Summary

ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header "X-Endpoint-API-UserInfo", the application can use it to do authorization. But if there are two "X-Endpoint-API-UserInfo" headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the backend application.

An attacker can send two "X-Endpoint-API-UserInfo" headers and make the second one as a malicious JWT claim. The backend application will receive two "X-Endpoint-API-UserInfo" headers, the first one is the correct one added by ESPv1 for the verified JWT token, the second one will be the malicious one from the client, the spoofed one.

Above only happens when the JWT authentication is required for the API method and the JWT token in the request has been successfully verified. This requires the attacker to be able to generate a valid JWT token that can be verified by ESPv1. For some tokens, such as Okta, auth0, it is not easy to generate a valid JWT token since the JWKS public keys are specific to certain accounts. It will be very difficult for the attacker to figure out the account number and to generate a good token for that account. For some tokens, such as Google ID token, and Firebase, it could be easy to generate a valid token since JWKS public keys are the same for all accounts.

Impact

This impacts following ESPv1 usages:

• Users have configured ESPv1 to do JWT authentication with Google ID Token or Firebase as described in this doc.
• Users backend application is using the info in the "X-Endpoint-API-UserInfo" header to do the authorization. The backend application should receive two "X-Endpoint-API-UserInfo" headers, and it is not deterministically using the first "X-Endpoint-API-UserInfo" header, may use the second one which could be malicious one spoofed from the client.

Patches

It has been fixed by the new release v1.58.0. You need to patch it in the following ways:

• If your docker image is using tag ":1", needs to re-start the container to pick up the new version. The tag ":1" will automatically point to the latest version. For example,

- name: esp
  image: gcr.io/endpoints-release/endpoints-runtime:1
  args: [
    "--http_port=8081",
    "--backend=127.0.0.1:8080",
    "--service=SERVICE_NAME",
    "--rollout_strategy=managed",
  ]

• If your docker image tag pings to a specific minor version, e.g. ":1.57". You need to update it to ":1.58" and re-start the container.

- name: esp
  image: gcr.io/endpoints-release/endpoints-runtime:1.57
  args: [
    "--http_port=8081",
    "--backend=127.0.0.1:8080",
    "--service=SERVICE_NAME",
    "--rollout_strategy=managed",
  ]

Workarounds

No