Mike Sherov mike.sherov at gmail.com
Fri May 1 16:30:49 UTC 2020

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:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution including
another new one in lodash today. https://snyk.io/vuln/npm:lodash:20180130

On Fri, May 1, 2020 at 12:13 PM Isiah Meadows <contact at isiahmeadows.com>

> Missed the list. Also, it apparently does trigger setters. Crossed it up
> with spread properties (which don't).
> On Fri, May 1, 2020 at 06:28 Isiah Meadows <contact at isiahmeadows.com>
> wrote:
>> I thought `Object.assign`already used the `Object.keys` +
>> `Object.defineProperty` algorithms under the hood and thus were immune to
>> this. Am I misremembering or misunderstanding?
>> On Fri, May 1, 2020 at 05:51 Mike Sherov <mike.sherov at gmail.com> wrote:
>>> 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.
>>> Thoughts?
>>> Mike Sherov
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> --
>> -----
>> Isiah Meadows
>> contact at isiahmeadows.com
>> www.isiahmeadows.com
> --
> -----
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com

Mike Sherov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200501/7a9957d3/attachment.html>

More information about the es-discuss mailing list