Make source-map-support work when the Object prototype is frozen

[jportner]

Background

Note: examples use the Node.js REPL with strict mode: node --use_strict.

Inheritance and Shadowing

Objects in JavaScript inherit properties from their prototype chain. For example, the "toString" property can be accessed on all objects, but it doesn't actually exist on each object, it exists on the global Object prototype:

let obj = {};
obj.toString();
// '[object Object]'
Object.getOwnPropertyDescriptor(obj, 'toString');
// undefined
Object.getOwnPropertyDescriptor(Object.prototype, 'toString');
// { value: [Function: toString], writable: true, enumerable: false, configurable: true }

Under normal circumstances, you can assign a property to an object using the = operator, and any property of the same name in the object's prototype chain will not be modified, but will be "shadowed" by the new property:

obj.toString = () => 'foo';
obj.toString();
// 'foo'
Object.getOwnPropertyDescriptor(obj, 'toString');
// { value: [Function: toString], writable: true, enumerable: true, configurable: true }

Prototype Pollution

From Snyk:

Prototype pollution is an injection attack that targets JavaScript runtimes. With prototype pollution, an attacker might control the default values of an object's properties. This allows the attacker to tamper with the logic of the application and can also lead to denial of service or, in extreme cases, remote code execution.

There are a few different ways to mitigate Prototype Pollution, and one way to do it across the board is to freeze the global "root" objects and their prototypes (Object, Function, Array, etc.)

From MDN:

The Object.freeze() static method freezes an object. Freezing an object prevents extensions and makes existing properties non-writable and non-configurable. A frozen object can no longer be changed: new properties cannot be added, existing properties cannot be removed, their enumerability, configurability, writability, or value cannot be changed, and the object's prototype cannot be re-assigned.

This means that any attempt to change the Object prototype will fail. If using strict mode, it will throw an error; otherwise, it will be silently ignored.

If the Object prototype becomes frozen, all of its properties are no longer writable or configurable:

Object.freeze(Object.prototype);
Object.getOwnPropertyDescriptor(Object.prototype, 'toString');
// { value: [Function: toString], writable: false, enumerable: false, configurable: false }

This also prevents shadowing properties with assignment. If an object doesn't already have a property defined (such as "toString"), and it inherits a non-writable property of that name from its prototype chain, any attempt to assign the property on that object will fail:

let obj2 = {};
obj2.toString = () => 'bar';
// Uncaught TypeError: Cannot assign to read only property 'toString' of object '#<Object>'
obj2.toString();
// '[object Object]'

This behavior is described in the ECMAScript 2016 specification:

Assignment to an undeclared identifier or otherwise unresolvable reference does not create a property in the global object. When a simple assignment occurs within strict mode code, its LeftHandSideExpression must not evaluate to an unresolvable Reference. If it does a ReferenceError exception is thrown (6.2.3.2). The LeftHandSideExpression also may not be a reference to a data property with the attribute value {[[Writable]]: false}, to an accessor property with the attribute value {[[Set]]: undefined}, nor to a non-existent property of an object whose [[Extensible]] internal slot has the value false. In these cases a TypeError exception is thrown (12.15).

The Problem

Unfortunately, this package uses assignment to shadow the "toString" function for call site frames of stack traces:

node-source-map-support/source-map-support.js

Line 364 in 7b5b81e

object.toString = CallSiteToString;

This means that projects cannot use this package if they have frozen the global Object prototype.

The Solution

You can still shadow non-writable prototype properties by explicitly defining a new data property on the object:

Object.defineProperty(obj2, 'toString', { value: () => 'bar' });
obj2.toString();
// 'bar'
Object.getOwnPropertyDescriptor(obj2, 'toString');
// { value: [Function: toString], writable: false, enumerable: false, configurable: false }

The cloneCallSite function can be changed to use this method of shadowing so it is compatible with this approach of mitigating Prototype Pollution 🎉

[LinusU]

The changes looks good to me 👍

Can you think of anything that would prevent this being released as a new patch version?

[jportner]

Can you think of anything that would prevent this being released as a new patch version?

Good question!

The existing approach that sets this property using the = operator makes the property writable, enumerable, and configurable.

On the other hand, this new approach using Object.defineProperty() makes the property non-writable, non-enumerable, and non-configurable by default.

I don't think it's likely, but I suppose there's a chance that some projects could be changing the toString property on one of these call site frames after source-map-support sets it. So, the safest thing to do for a patch release would be to make sure the property descriptor is exactly the same as before. IMO this doesn't introduce any security risk for consumers because this property is only present on individual objects, not on any prototypes.

I pushed 1a14441 to make this change. With that, I think this is definitely safe to release as a patch version 👍

[jportner]

@LinusU if you don't have any other concerns, would you be willing to merge/release this change? 🙏

[jportner]

I ran into this problem again with another package that includes source-map-support in its distributable, so I thought I would come back and give this PR a friendly bump 😄

I also realized that when I pushed 1a14441, I forgot to rebuild the browser JS file, so I updated that too in 1bb6321