mesqueeb
commented
3 years ago @jayateertha043 I'm planning to still look into prototype pollution a bit more.
I originally had this idea that my libraries are not responsible to limit copying/merging of a prototype, because what if someone needs to do that in their software, just stripping the ability to do so makes my library un-usable to them.
However, since it seems like other libraries do prevent this by default, I might reconsider. I might create 2 versions, one that prevents copying/merging of the prototype, and one that allows it. If I do make 2 versions, I'll be very explicit in the docs about when to use which one.
I'm gonna keep this open a while until I make a final decision.
Hi , There were may utilities similar to yours which offered deep copying,cloning and merging functionalities. I suggest there should always be a check when key is proto,prototype and constructor.(This should be a easy fix) as we don't how how anyone is using your package, If someone using your package directly passes user input to copy function it might severely affect their business logic.
Your package is used by many large organizations like less.js, So we don't exactly know how they use it(safely or not). Most of them directly pass user input without filtering for these keys.
This may cause severe business logic errors.
Here are few report very similar to this which was accepted and fixed by the opensource community: https://huntr.dev/bounties/1-npm-smart-extend/ https://huntr.dev/bounties/1-npm-@livelybone/copy/
Here are few similar reports fixed by our community: https://github.com/fabiospampinato/plain-object-merge/pull/1 https://github.com/Geta/NestedObjectAssign/pull/11
To know more about Prototype Pollution: https://codeburst.io/what-is-prototype-pollution-49482fc4b638
If you need any other details regarding this , please feel free to contact me in twitter or comment here.
Sorry, Closing the issue I think it's intended behaviour.