• (nodebb)

    Agree about probable overkill.... Now if they had captured the patch into a variable and done SOMETHING (even looked at in a debugger), then it might just have been a very good solution if the circumstances are right... For example, if 999 out of 1000 times they are the same, then the entire sets need to be examined, it is in only 0.1% of the cases where there would be a performance difference. Now how much of a difference, what if the structure is complex, but the content is only a few K...

  • Anon (unregistered)

    That's not really a vulnerability, the consumer of the library may actually want to change the prototype of an object.

  • (author) in reply to Anon

    The reason it's a vulnerability is that a JSON document could change the prototype of an object (or Object). Generally, inputs to your program shouldn't just change your code.

  • (nodebb)

    Patch creator was not patched, then?

  • Anon (unregistered) in reply to Remy Porter

    If the non-sanitized input is passed to the method, but that's also true for "eval" and have similar problems when using SQL, in the case of article the "vulnarability" is not even exploitable.

  • ZZartin (unregistered)

    Wouldn't that only be a vulnerability if you actually ran the patch it generated?

  • ooOOooGa (unregistered) in reply to Anon

    Anyone who uses 'eval' in their code and says that their code is secure is in for a rude awakening in very short order.

  • cschneid (unregistered)

    I thought inputs being able to modify your code was a feature of interpreted languages.

  • How Deep is Your Love? (unregistered)

    I like the stackoverflow approach, except I think you can have cycles in javascript objects, since JSON.stringify() fails on them.

Leave a comment on “Patching Over Your Problem”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article