Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie

Summary

The forge.http client stored cookies from Set-Cookie response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name __proto__ to add properties to Object.prototype, use inherited names such as constructor to add properties to Object, and send an empty cookie value to delete Object.prototype properties. Fixed in node-forge 1.4.1.

Details

client.setCookie() in lib/http.js stored a cookie with client.cookies[cookie.name][cookie.path] = cookie, creating client.cookies[cookie.name] only when !(cookie.name in client.cookies). Both values come from the server's Set-Cookie header via response.getCookies(). Because in also sees inherited properties:

• a cookie named __proto__ skipped the initialization, client.cookies['__proto__'] returned Object.prototype, and the cookie path was written as a new Object.prototype property, visible on every object;
• a cookie named constructor wrote onto the global Object function the same way;
• a cookie with an empty value calls client.removeCookie(name, path), which used the same in checks and then delete client.cookies[name][path], so Set-Cookie: __proto__=; path=toString deleted Object.prototype.toString. This path skipped the cookie's secure-flag and domain checks, so it also worked for http:// clients.

forge.http is not loaded by require('node-forge'). It is included in the forge.all browser bundle and is used with a socket pool, for example by forge.xhr.

The fix uses own-property checks for the cookie store and ignores cookies named __proto__ or with the path __proto__.

Patches

Fixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of Object.prototype or Object.

Workarounds

Don't use forge.http or forge.xhr with servers that aren't trusted, or filter Set-Cookie headers named __proto__, constructor or other Object.prototype property names before they reach the client.

Credits

Reported by @arunmozhivarman-dtx and @Dremig.

Proof of concept

A server response for a forge.http client (http.createClient({url: 'https://...', socketPool: ...})) containing:

Set-Cookie: __proto__=evil; path=polluted

On 1.4.0, after the client processes the response, ({}).polluted is the cookie object. With Set-Cookie: __proto__=; path=toLocaleString, Object.prototype.toLocaleString is deleted (for http:// and https:// clients). On 1.4.1 these cookies are ignored and Object.prototype is unchanged.

Regression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js.

Impact

Applications that use the forge.http client (directly, or through forge.xhr in the forge.all browser bundle) against a server that can be malicious are affected. The server can add properties to Object.prototype and Object for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in Object.prototype methods, breaking the page or process. Applications that don't use forge.http are not affected.