"Script error." message in window.onerror makes bad DevExp trade off

[cramforce]

When a script that isn't served from the same origin as the document throws an error, then the error message exposed to window.onerror is "Script error." and the stack trace is empty.

This is to spec and it can be worked around in some browsers by

• serving the script with CORS headers
• requesting the script as CORS.

While the behavior is understandable, it leads to bad developer experience in practice and is overzealous with respect to the threat model.

My understanding of the threat model is that it is worried about attackers circumventing CORS restrictions by e.g. script src-ing a privileged file from a cross origin and then gaining insights from the error message that happens because the file is not valid JavaScript.

I think browsers could successfully prevent the threat while maintaining most of the developer experience:

• The "Script error." rewriting should be limited to initial execution of a script, because all other stack entry points can be wrapped in try-catch and hence aren't subject to the limitation anyway.
• Potentially the rewriting of the error message could be limited to SyntaxError only.

Since SyntaxErrors are essentially irrelevant in JavaScript production monitoring, these changes would reinstate the ideal developer experience while maintaining the desired protection against data leaks.

As an additional data point: Safari& Chrome seem to follow the spec but Edge & IE do not handle cross origin errors specifically at all and provide full exception info.

[annevk]

I recommend filing a (security) bug against Edge.

I don't see why we would potentially compromise security of users or complicate JavaScript's processing model when the alternative is rather easy to deploy and works everywhere.

[cramforce]

What is the added benefit of the error obfuscation for non-initial execution errors?

Since JS can instrument all other stack entry points this protection effectively only applies to initial execution.

Try even googling for "Script error.". There are 2 obscure blog posts explaining what is going on and a lot of confused developers that wonder why their stuff just doesn't work after they deployed using a CDN in production. Meanwhile people use the mentioned above stack entry point instrumentation to fix things mostly for them (See Angular Zones, goog.debug.entryPointRegistry, and dozens of commercial error monitoring services that could be one line of JS if it wasn't for the above). So, what happens is that the "complicated processing model" you mention was shifted into user space, making JS slower for everyone everywhere.

[annevk]

What is the added benefit of the error obfuscation for non-initial execution errors?

I'm not entirely sure, but I don't think the burden is on me to proof that it doesn't reveal any new data.

I understand that running into this is frustrating, but the answer here is CORS and it doesn't make JS slower for everyone everywhere. Poking more holes in the same-origin policy is not a good solution.

[cramforce]

The answer to the question is that there is no benefit as proven in subsequent paragraph.

If spec simplicity is more important than developer experience, sure I understand your point, but some developers may disagree.

[annevk]

The answer to the question is that there is no benefit as proven in subsequent paragraph.

I don't see how that's true though, e.g., with closures.

[annevk]

If spec simplicity is more important than developer experience, sure I understand your point, but some developers may disagree.

I don't think this is warranted.

[cramforce]

@annevk Do you have an example for how to run JS in a browser outside of script tag injection's immediate side effect that cannot be wrapped as an entry point as in

const orig = window.setTimeout;
window.setTimeout = function(fn, timeout) {
  orig(function() {
    try { return fn.apply(this, arguments) } catch (e) { console.log(e.stack) /* full stack trace */ }
  }, timeout)
};

I'm not aware of a way that JS gets run outside of initial execution where a sufficiently motivated attacker couldn't change it so that they get to wrap that execution in a try block. Do you have an example?

[annevk]

If the foreign script uses Promise.then() or registers event listeners?

[cramforce]

You can (and this is what all the tools do), just override Promise, Promise.prototype.then and Foo.prototype.addEventListener just before running the foreign script.

Of course, this makes execution slower since every API call is going through an extra closure and try-block.

[annevk]

If that leaves no holes and the exception you get is otherwise identical that is somewhat compelling. Did you talk to Chrome's security team about this?

[domenic]

We're certainly not going to poke more holes in the same-origin policy. Please use CORS.

[cramforce]

@annevk Yes, talked to @mikewest. https://bugs.chromium.org/p/chromium/issues/detail?id=701371#c1

@domenic Not proposing to poke a new hole. Just make an existing hole benefit developers instead of only attackers.

[bzbarsky]

So a few thoughts:

1. There is no spec that requires exceptions to have any location information, nor any specifically useful error messages. Of course in practice in UAs they have both, though not in interoperable ways.

2. I agree that by the time you're running script you're more or less SOL because an attacker can hook all the global objects and intercept most of what you're doing. Thus, while we could extend the muted error protections into what's available from JS exception objects in general, in practice it probably doesn't help much.

3. We have added restrictions on what could be hooked in the past. For example see the changes to disallow adding a proxy on the proto chain of the global (to prevent interception of arbitrary barewords in the script text). There's also still some thought going on wrt what can be done with getters/setters on the global, if anything, which allow targeted interception of specific barewords.

4. Given item 2, I expect that in practice restricting error muting to invalid syntax and "early errors" in ES parlance is probably reasonable. Given item 3 I'm not 100% sure of it, and it could change in the future. So we need to be a bit careful here. :(

5. Not all early errors are SyntaxErrors, so restricting error muting to SyntaxError is definitely wrong. Simple example from a few minutes of reading the ES spec: <script>(()=>{})++</script> produces an unhookable ReferenceError, not SyntaxError. Not all UAs get this right, of course (e.g. Firefox produces a SyntaxError here).

6. "Initial execution" is a bit hard to define rigorously (unlike early errors). But early errors are somewhat orthogonal to "initial execution", given eval. And eval is hookable, and both syntax errors and early errors in it are catchable too. So for maximum usefulness you would want to do something like mute early errors coming from non-eval executions or something...

7. You really need to talk to some ES experts to make sure they're not planning to add features that will blow up some or all of the assumptions about this.

Paging @syg and @jswalden for this last bit and more hard data on what the state of mitigations I mention in item 3 is.