Object.safeAssign

Augusto Moura augusto.borgesm at gmail.com
Fri May 8 17:46:27 UTC 2020


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>
escreveu:

> 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>
> wrote:
>
>> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


-- 
Atenciosamente,

Augusto Borges de Moura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200508/909f20b1/attachment.html>


More information about the es-discuss mailing list