Open holgerkoser opened 1 month ago
If the alternate works, sounds good to me.
I would also like to add that freezing the constructors and prototypes after xterm.js
is loaded is not an option for me. Since xterm.js
is a relatively large library, I only want to load the code when a terminal window is actually opened by the user. In most cases, this doesn't happen, so it would be inefficient to include xterm.js
in the initial bundle.
I'm trying to implement protection against prototype pollution in my SinglePageApp that uses xterm.js. I'm using the following code at initialization:
However, this causes an error when xterm.js tries to create a decorator:
The error seems to originate from this line in
ServiceRegistry.ts
: https://github.com/xtermjs/xterm.js/blob/master/src/common/services/ServiceRegistry.ts#L36 It appears that the decorator creation is trying to modifyFunction.prototype
, which is no longer allowed due to theObject.freeze()
call.To reproduce the problem more simply:
This returns the same error.
Proposed solution: Instead of using
toString
to store the id, consider using a different property name (e.g.,decorator._id = 1
) or a Symbol. This would allow the decorator to function without modifyingFunction.prototype
. Is it possible to implement the decorator functionality using one of these alternative approaches? This would allow users to implement stronger prototype pollution protections without breakingxterm.js
functionality.