11 ms·
Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving
by filearts 10mo ago
Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.
- mirashii 10mo agoThis comment from a dupe thread is worth considering: https://news.ycombinator.com/item?id=46137352 https://news.ycombinator.com/item?id=46137352
- harrall 10mo agoI see this type of vulnerability all the time. Seen it in Java, Lua, JavaScript, Python and so on. I think deserialization that relying on blacklists of properties is a dangerous game. I think rolling your own object deserialization in a library that isn’t fully dedicated to deserialization is about as dangerous as writing your own encryption code.
- int_19h 10mo agoOnly if you're deserializing into objects with behavior.
- ectospheno 10mo agoWhat does data in a program do apart from eventually modify behavior?
- mary-ext 10mo agonot `__proto__` but likely `constructor`, if you access `({}).constructor` you'd get the Object constructor, then if you access `.constructor` on that you'd get the Function constructor the one problem I haven't understood is how it manages to perform a second call afterwards, as only being able to call Function constructor doesn't really amount to much (still a serious problem though)