JWT authentication bypass via 'X-HTTP-Method-Override' Header

Summary

The video discusses a security vulnerability in ESP version 2, which allows API clients to bypass JWT authentication by adding a specific header, the 'X-HTTP-Method-Override', to their requests. This header can manipulate HTTP methods like POST or PUT, allowing attackers to bypass security checks under certain conditions. The vulnerability was identified in the context of Google Cloud's ESP infrastructure, which is used to secure APIs. The video also covers the mitigation strategy, which involves upgrading to ESP version 2.43.0 or higher to ensure JWT authentication checks even when the override header is used.

Takeaways

• 😀 A vulnerability in ESP version 2 allows bypassing JWT authentication by adding a specific header to the request.
• 😀 ESP (Extensible Service Proxy) is an infrastructure service that helps secure APIs using Google Cloud endpoints.
• 😀 The X-HTTP-Method-Override header allows clients to bypass certain HTTP method restrictions, e.g., using PUT in place of POST.
• 😀 The vulnerability in ESP version 2 allows attackers to bypass JWT authentication when certain conditions are met.
• 😀 In the attack scenario, an API client sends a POST request but overrides it to PUT using the X-HTTP-Method-Override header.
• 😀 ESP forwards the request to the backend without checking the JWT if the requested HTTP method is not in the service definition.
• 😀 For the attack to succeed, the requested HTTP method (like PUT) must not be defined in the API service, and the X-HTTP-Method-Override header must be allowed.
• 😀 The issue is mitigated in ESP version 2.43.0 and higher, which ensures JWT authentication is checked even with the X-HTTP-Method-Override header.
• 😀 The vulnerability was discovered in ESP version 2, which is designed to be fully managed, scalable, and to secure APIs with Google Cloud.
• 😀 The video encourages viewers to leave suggestions for future content, especially related to API hacking.
• 😀 Viewers are reminded to update their ESP deployments to version 2.43.0 or higher to avoid this vulnerability.

Q & A

What vulnerability is discussed in the script?

The script discusses a vulnerability in ESP (Envoy Service Proxy) version 2 that allows an API client to bypass JWT (JSON Web Token) authentication by adding a specific header to the request.

What is ESP and what role does it play in securing APIs?

ESP (Envoy Service Proxy) is a fully managed, scalable, and highly available infrastructure used to secure APIs by utilizing Google Cloud endpoints. It helps protect APIs and monitor their usage.

What is the X HTTP Method Override header?

The X HTTP Method Override header is used to bypass certain HTTP methods that are not available in specific cases, like when an API or its consumer is behind a firewall. It allows the emulation of different HTTP methods such as PUT using only POST.

How does the X HTTP Method Override header work in this vulnerability?

The X HTTP Method Override header allows a malicious API client to send a PUT request over a POST request. If ESP is configured to only allow POST requests with a valid JWT token, the attacker can bypass authentication by adding the X HTTP Method Override header.

What are the two conditions for this vulnerability to work?

The vulnerability works under two conditions: (1) The requested HTTP method (like PUT) is not in the API service definition, and (2) the API service allows the X HTTP Method Override header to be used.

What happens when an attacker exploits this vulnerability?

The attacker can craft a request that bypasses JWT authentication by using the X HTTP Method Override header, causing the ESP to forward the request to the backend without checking the JWT.

How did ESP mitigate this vulnerability?

ESP mitigated the vulnerability by releasing version 2.43.0 or higher, which ensures that JWT authentication is enforced even when the X HTTP Method Override header is specified in the request.

What is the significance of upgrading to ESP version 2.43.0 or higher?

Upgrading to ESP version 2.43.0 or higher ensures that JWT authentication occurs even when the X HTTP Method Override header is used, thus protecting APIs from the described bypass vulnerability.

What kind of attack is this vulnerability related to?

This vulnerability is related to API hacking, specifically targeting the bypass of authentication mechanisms like JWT by manipulating HTTP headers.

How can API clients protect themselves from this vulnerability?

API clients should ensure they are using ESP version 2.43.0 or higher, and also avoid misconfiguring their API service to allow X HTTP Method Override headers in sensitive endpoints.