Mike Sherov mike.sherov at gmail.com
Fri May 1 15:47:44 UTC 2020

After a conversation on twitter (
https://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.

On Fri, May 1, 2020 at 8:50 AM 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

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

More information about the es-discuss mailing list