Hacker News new | ask | show | jobs
by redmorphium 2144 days ago
Concretely, at least on Node:

    const myData = {};
    myData[rawUserInput()].key = value;

This is vulnerable if rawUserInput() returns `__proto__`: `key` on the prototype may be set to value if `myData` had `__proto__` set. If the hacker controls `key` and `value` then they can effectively modify `key` field on all objects.

https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/...

A common way is as described by that paper ^

Recursive merge functions, unless if they check for this vulnerability, are often susceptible, since JSON.parse defines __proto__ on its return values.

1 comments

Indeed, though you'll only manage to break or DDOS the server by doing that.

It seems that the Ghost vulnerability explained in the paper relied on the handlebars engine calling the equivalent of `eval()` on a string value, in the global scope, plus a path traversal vulnerability allowing loading a template from node_modules.

Are there are any other examples of this being exploited in a meaningful way? Even if you end up passing raw user input to key and value, user payloads will never be able to define a function, so the possibilities are very limited. I think having every NPM library that does object assignment using a user-provided key be marked as 'vulnerable to prototype pollution' is quite different from it 'being a problem very often' in practice. Happy to be shown otherwise.

It could be serious.

Let's say your company's code is open-source, and the attacker knows there is code somewhere like this:

    let state = getState(); // returns empty {} if user not authenticated

    if (!state.userIsAuthenticated) {
       respond(401);
    }

    showBankAccount();

If the hacker is able to set `Object.prototype.userIsAuthenticated` then the auth check is now bypassed.

So I think the break / DDOS is pretty serious here.