hasOwnProperty usage

[isaacs]

These should use Object.prototype.hasOwnProperty.call instead of obj.hasOwnProperty.

lib/_debugger.js:    if (proto.hasOwnProperty(i) && ignored.indexOf(i) === -1) {
lib/module.js:  if (packageCache.hasOwnProperty(requestPath)) {
lib/querystring.js:    if (!obj.hasOwnProperty(k)) {
lib/repl.js:          if (!uniq.hasOwnProperty(c)) {

Causes server crashes when jerks request /foo?hasOwnProperty=x&y=z

[isaacs]

Should be fixed in 0.4 as well as 0.5

[felixge]

I understand how the querystring module might be effected, but what problem do you see with the other modules?

[indutny]

Debugger shouldn't be affected by this, because Object builtin can't be extended before debugger starts running.

[isaacs]

In general, any time there's an object used as a dictionary for arbitrary user-defined strings, it's a bad idea to depend on hasOwnProperty not being overridden.

mkdir -p node_modules
cat >./node_modules/hasOwnProperty <<END
console.log("has pwn properties!")
END

Then doing require("hasOwnProperty") in a node program makes the module system be in a really oddball state.

[indutny]

Ok, you persuaded me. fix is coming soon

[indutny]

#1712

[tshinnic]

Umm yeah, all this was the meaning behind #1637
"unguarded fs.watchFile cache statWatchers checking fixed"
where using a filename of 'hasOwnProperty' would blow up the code.

The filename was 'injected' into the object and then later when queried bad things happened. Hey, this is "sql injection" all over again, yes?