mikesamuel
commented
4 years ago @erights As discussed in person, IsCodeLike is not meant to preserve security properties; security properties about what can execute are in the host callout, so the fact that any user code can add a symbol is not security significant. It just allows more consistency in the host callout since host callouts don't need to do checks like "if called via eval and the argument is not a string or a value I consider codelike."
There are backwards compatibility concerns with eval that might arise if we were to just have eval always stringify.
{
let NaN = 42;
isNaN(eval(0/0)); // -> true
isNaN(eval(String(0/0))); // -> false
}
// If we always stringified, both would always -> true@waldemarhorwat
As discussed in person, the threat model is that an attacker may control strings, numbers, and so may craft the kinds of objects that you might get from JSON.parse(x).
We want to keep those away from eval, so are concerned with
// In the absence of CSP
const attackerControlledString = ' ["alert(1)"] ';
eval(JSON.parse(attackerControlledString)); // currently just returns an array
koto
waldemarhorwat
lukewarlow
@erights @waldemarhorwat have ideas.
+ @bakkot too since failure to resolve concerns from issue #1 would obviate this.