Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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__.


I 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.


Only if you're deserializing into objects with behavior.


What does data in a program do apart from eventually modify behavior?


not `__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)


This comment from a dupe thread is worth considering: https://news.ycombinator.com/item?id=46137352




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: