Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. 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 application. An attacker can send two X-Endpoint-API-UserInfo headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the X-Endpoint-API-UserInfo header to do the authorization. It has been fixed by 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. * 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. There are no workaround for this issue.
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Extensible_service_proxy | * | 1.58.0 (excluding) |