Closed hyperupcall closed 3 months ago
Thank you, this is a very interesting found! Luckily, there's no prototype pollution, if keys constructor
or __proto__
are used in an object. But there's a bug that the duplicates are checked not only in the own object, but down to the prototype. I'm going to fix it in the upcoming release.
If I use this input file:
{
"answer": 42,
"constructor": "value",
"__proto__": { "polluted": true }
}
And I don't enable checking the duplicates, all keys are preserved, because that's how JSON.parse
fills the object keys in the result:
❯ jsonlint test.json
{
"answer": 42,
"constructor": "value",
"__proto__": {
"polluted": true
}
}
But if I enable the custom JSON parser by allowing comments in the input (or by other options from the JSON5 mode), the keys constructor
and __proto__
are "sanitized" away:"
❯ jsonlint --comments test.json
{
"answer": 42
}
So, somebody will say that it's great that property pollution cannot happen however the parsed output will be used, but somebody else may say that it's a data loss, skipping the special object keys. In any case, the behaviour of the custom JSON parser is different from JSON.parse
. I will do something about this in the next major version.
I made the custom parser behave just like the built-in JSON.parse
- letting all prototype keys be parsed by default. If the old default behaviour is needed, the argument ignore-prototype-keys
can be added to the command line, or the option ignorePrototypeKeys
can be set to true
, when calling the parse
method.
If you don't have under control, what will happen with the parsed object, you should consider setting ignoreProtoKey
to true
, when calling the parse
method, to prevent prototype pollution by merging the __proto__
key value to an object.
Awesome, thank you so much!
Reproduction
Output:
This may potentially be a prototype pollution vulnerability for constructor? Anyways, thank you for the work you have done on this package.