fix(encoding/jsonc): avoid prototype pollution in Node.js and Browser

[ayame113]

related: CVE-2022-46175

Using encoding/jsonc with Node.js and browsers is currently vulnerable to prototype pollution (in the form described in the CVE-2022-46175).

This PR changes the behavior of jsonc.parse when trying to set __proto__ as a key in Node.js and browsers.

This PR does not change behavior when running in Deno. This is because __proto__ has been removed within Deno and is already robust against prototype pollution attacks.

[lino-levan]

Not sure if this makes sense for the std. It seems to be making the code harder to read with very little gain for its intended place of consumption. I do see an argument for browsers since iirc this module is considered browser compatible but given that it is non-trivial to get this running directly in a browser due to typescript, I would not be concerned about __proto__ vulnerabilities personally. I'm not super strongly against this change, just my 2 cents.

Also, I'm personally -1 for adding a dependency to node here.

[ayame113]

We can use esb.deno.dev, deno.land/x/emit and dnt to run this module in the browser or Node.js.

In my opinion, when it comes to code readability and security, security should take precedence. (For reference, the content of the fix is the same as the fix done in JSON5.)

Also, the behavior in current browsers simply looks buggy. i want to fix this.

Also, I'm personally -1 for adding a dependency to node here.

I agree with this.
I thought about this again, by overriding the setter of __proto__ and testing it, it may be possible to test without relying on Node.js. I'll try later.

Edit: I have done this, and it works great. There is no dependency on Node.js anymore.

[kt3k]

Fixing for browser security makes sense to me

[lino-levan]

Sorry about not having time to review this earlier. In its new form, this LGTM!

My biggest concern before was regarding CI but now that this has been fixed, this seems like an obvious fix.

[kt3k]

LGTM