# Mike Sherov (4 years ago)

Given the increased prevalence of prototype pollution vulnerabilities in many popular javascript libraries, is it time to reconsider the fact that Object.assign allows for prototype pollution by default?

I see two options:

  1. Change Object.assign to disallow PP by default. Look at real world usages and see what would break if prototype pollution was disabled? Almost certainly this is not a viable option, but wanted to raise it here just in case there was appetite to do so.
  2. Introduce something like Object.safeAssign (bikeshedding aside), that is the same as Object.assign except is safe from prototype pollution.

The reason I think this is important is that the common advice of freezing Object.prototype is something only the end user can do, and not something a library can do.

Yes, a library can also know to do its own PP fixes, but having a reified way to avoid PP allows us to have a secure-by-default method in the language.


Mike Sherov

# Mike Sherov (4 years ago)

After a conversation on twitter ( twitter.com/mikesherov/status/1256193257626836998?s=20), to firm up what I'm proposing here is that preventing prototype pollution isn't really possible with Object.assign as is because it would have to change to not execute setters, which is a non-starter.

I'm mostly left with a desire to discuss/learn what it would actually take to make a prototype pollution safe version of Object.assign, and this may not be the forum for that.

# Isiah Meadows (4 years ago)

Missed the list. Also, it apparently does trigger setters. Crossed it up with spread properties (which don't).

# Bob Myers (4 years ago)

Can you explain or support your assertion of "increased prevalence"?

# Jordan Harband (4 years ago)

I'm confused about that as well; there were a spate of CVEs about it a year or two ago (2 or 3 of my libraries were "affected"), but just like the minimist/mkdirp ones, they were only actually vulnerabilities for a minority of the use cases. Have there been any recent vulnerabilities you're aware of?

# Mike Sherov (4 years ago)

So, I've firmed up my understanding here. The goal of a safeAssign would not be to prevent all prototype pollution, which seems impossible to solve generically at a library level. But rather to prevent the assignment specifically of __proto__, constructor, and prototype properties of the target. This mitigates a specific, well understood vulnerability: manipulating a prototype with a "src" object that can surive a JSON.parse(JSON.stringify(src)) roundtrip.

Can you explain or support your assertion of "increased prevalence"?

I should probably have said visibility, not prevalence. MITRE shows 31 CVEs for prototype pollution: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution including another new one in lodash today. snyk.io/vuln/npm:lodash:20180130

# Mike Sherov (4 years ago)

I'll drop this thread for now, and come back when I've actually thought this all through. Sorry for wasting your time!

# Augusto Moura (4 years ago)

The real risk are the exploits that are not made public

In my opinion proto as a whole should be the one to be dropped, unfortunately this is not happening in the near future. My hope is that one day, years after now, the usage is so low that it can be removed from the language. That would solve a big list of exploits. I don't see that much of a problem with setting constructor or prototype though. Maybe we should promote a more aggressive deprecation? Discuss with browsers to log warnings and make more explicit in documentation the hazards with counting on it. Anyway maybe the problem are not serious enough to get that attention.

Em sex., 1 de mai. de 2020 às 13:31, Mike Sherov <mike.sherov at gmail.com>