Chaining Method Override and CSRF Vulnerabilities for Account Takeover

Chaining Method Override and CSRF Vulnerabilities for Account Takeover

As a security researcher, uncovering vulnerabilities that could potentially lead to severe security breaches is both challenging and rewarding. In this post, I will discuss a fascinating case involving method override and Cross-Site Request Forgery (CSRF) vulnerabilities, which could lead to an account takeover. Please note that the actual site involved cannot be disclosed, so we will refer to it as “site.com.”

Understanding Key Terminology

Before diving into the exploit details, it’s important to understand the key concepts involved:

Method Override: In RESTful APIs, clients can communicate with servers using various HTTP methods, such as GET, POST, PUT, and DELETE. While HTML forms traditionally support only GET and POST, developers sometimes implement a technique called method override to allow forms to submit requests using other methods, like PUT or DELETE. This is typically achieved by including a query parameter or request header that specifies the desired method. For example, a POST request to api.site.com/person/v1/account?_method=PUT would instruct the server to treat the request as a PUT operation.

Cross-Site Request Forgery (CSRF): CSRF is an attack where a malicious website tricks a user’s browser into making an unwanted request to another site where the user is authenticated. This can lead to unauthorized actions, such as changing account settings, without the user’s knowledge. CSRF exploits the trust that a site has in the user’s browser.

Content-Type Restriction: When making HTTP requests, the Content-Type header indicates the media type of the request body. For security, some APIs restrict this header to specific values, like application/json, to prevent unauthorized or unintended requests.

The Vulnerability: Method Override and CSRF Attack Vector

In this particular case, the API endpoints within api.site.com/person/v1/* were found to be vulnerable due to their use of method override and lack of CSRF protection.

1. Method Override Mechanism: The site.com API allowed clients to override the HTTP method used in API calls through a query parameter or header. This feature, while not inherently insecure, became problematic due to the absence of CSRF protections.
2. Lack of CSRF Protection: The absence of CSRF protection meant that an attacker could craft a malicious request on a separate website that, if visited by an authenticated user of site.com, would execute actions on their behalf. Normally, CSRF protections, such as anti-CSRF tokens, prevent such attacks by ensuring that the request is legitimate and initiated by the user.

The Exploit Scenario

Imagine an API endpoint api.site.com/person/v1/account that accepts PUT requests to update user account details like email, phone number, etc. If an attacker can change a user’s email address, they can potentially hijack the account by resetting the password.

Here’s how the exploit unfolds:

1. Setting Up the Attack: The attacker creates a malicious webpage containing a form that sends a POST request to api.site.com/person/v1/account?_method=PUT. This request includes parameters to change the victim’s email address.
2. Bypassing Same-Origin Policy: Typically, browsers enforce the Same-Origin Policy, preventing cross-site requests from being executed. However, if the API allows method override with POST requests and does not enforce strict Content-Type checks (allowing application/x-www-form-urlencoded), the request bypasses the browser’s pre-flight CORS checks, which are normally triggered by non-simple requests.
3. Executing the Attack: When the victim visits the malicious webpage while authenticated on site.com, the form auto-submits, sending the crafted request to the API. The server processes the request as a PUT request (due to method override), updating the user’s email address to one controlled by the attacker.
4. Account Takeover: The attacker can now request a password reset, receiving the reset link at the new, attacker-controlled email address, thereby taking over the account.

Conclusion and Responsible Disclosure

This vulnerability, combining method override misuse and lack of CSRF protection, demonstrated how seemingly benign features could be exploited for severe attacks like account takeover. After discovering this issue, we reported it to the vendor of site.com. We are pleased to report that they responded promptly and have since implemented appropriate security measures, including disabling the method override feature and adding CSRF protection, to secure their API endpoints.

This case highlights the importance of rigorous security practices in web application development, especially around API design and user data protection. As always, responsible disclosure and collaboration between researchers and vendors are crucial in keeping the digital ecosystem secure.