<div dir="ltr">The real risk are the exploits that are not made public<br><br>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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 1 de mai. de 2020 às 13:31, Mike Sherov <<a href="mailto:mike.sherov@gmail.com">mike.sherov@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>> Can you explain or support your assertion of "increased prevalence"?<br></div><div><div><br></div><div>I should probably have said visibility, not prevalence. MITRE shows 31 CVEs for prototype pollution: <a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution" target="_blank">https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prototype+pollution</a> including another new one in lodash today. <a href="https://snyk.io/vuln/npm:lodash:20180130" target="_blank">https://snyk.io/vuln/npm:lodash:20180130</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 12:13 PM Isiah Meadows <<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Missed the list. Also, it apparently does trigger setters. Crossed it up with spread properties (which don't).</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 06:28 Isiah Meadows <<a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">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?</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 05:51 Mike Sherov <<a href="mailto:mike.sherov@gmail.com" target="_blank">mike.sherov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?<br>
<br>
I see two options:<br>
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.<br>
2. Introduce something like Object.safeAssign (bikeshedding aside), that is the same as Object.assign except is safe from prototype pollution.<br>
<br>
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. <br>
<br>
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.<br>
<br>
Thoughts?<br>
<br>
Mike Sherov<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div></div>-- <br><div dir="ltr">-----<br><br>Isiah Meadows<br><a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br><a href="http://www.isiahmeadows.com" target="_blank">www.isiahmeadows.com</a></div>
</blockquote></div></div>-- <br><div dir="ltr">-----<br><br>Isiah Meadows<br><a href="mailto:contact@isiahmeadows.com" target="_blank">contact@isiahmeadows.com</a><br><a href="http://www.isiahmeadows.com" target="_blank">www.isiahmeadows.com</a></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Sherov<br><br></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Atenciosamente,<br><br>Augusto Borges de Moura</div>