HTTP Parameter Pollution Leads to reCAPTCHA Bypass
31.5.18 securityweek Security

Earlier this year, a security researcher discovered that it was possible to bypass Google’s reCAPTCHA via HTTP parameter pollution.

The issue, application and cloud security expert Andres Riancho says, can be exploited when a web application crafts the request to /recaptcha/api/siteverify in an insecure way. Exploitation allows an attacker to bypass the protection every time.

When a web application using reCAPTCHA challenges the user, “Google provides an image set and uses JavaScript code to show them in the browser,” the researcher notes.

After solving the challenge, the user clicks verify, which triggers an HTTP request to the web application, which in turn verifies the user’s response with a request to Google’s reCAPTCHA API.

The application authenticates itself and sends a {reCAPTCHA-generated-hash} to the API to query the response. If the user solved the challenge correctly, the API sends an "OK" that the web application receives, processes, and most likely grants the user access to the requested resource.

Riancho discovered that an HTTP parameter pollution in the web application could be used to bypass reCAPTCHA (the requirement, however, reduced the severity of the vulnerability).

“HTTP parameter pollution is almost everywhere: client-side and server-side, and the associated risk depends greatly on the context. In some specific cases it could lead to huge data breach, but in most cases it is a low risk finding,” Riancho explains.

He notes that it was possible to send two HTTP requests to Google’s service and receive the same response. The reCAPTCHA API would always use the first secret parameter on the request but ignore the second, an issue the researcher was able to exploit.

Additionally, Google is providing web developers interested in testing their web applications with a hard-coded site and secret key to disable reCAPTCHA verification in staging environments and perform their testing, and the bypass leverages this functionality as well.

“If the application was vulnerable to HTTP parameter pollution AND the URL was constructed by appending the response parameter before the secret then an attacker was able to bypass the reCAPTCHA verification,” the researcher notes.

Two requirements should be met for the vulnerability to be exploitable: the web application needs to have an HTTP parameter pollution flaw in the reCAPTCHA URL creation, and to create the URL with the response parameter first, and then the secret. Overall, only around 3% of reCAPTCHA implementations would be vulnerable.

Riancho points out that Google addressed the issue in the REST API by returning an error when the HTTP request to /recaptcha/api/siteverify contains two parameters with the same name.

“Fixing it this way they are protecting the applications which are vulnerable to the HTTP Parameter Pollution and the reCAPTCHA bypass, without requiring them to apply any patches,” the researcher notes.

The issue was reported to Google on January 29, and a patch was released on March 25. The search giant paid the researcher $500 for the discovery.