New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include the string to be compiled in the call to `HostEnsureCanCompileStrings` #938

Open
mikewest opened this Issue Jun 21, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@mikewest

mikewest commented Jun 21, 2017

To improve the quality of CSP reports, it would be helpful for HostEnsureCanCompileStrings() to include the string to be compiled as an argument. HostEnsureCanCompileStrings(callerRealm, calleeRealm, source) seems ideal. :)

The goal is to ensure that we can include a sample of the script which violates the policy when generating a CSP violation report. We're doing this for inline <script>...</script> blocks today, and layering eval() and the like on as well would be helpful.

@domenic

This comment has been minimized.

Member

domenic commented Jun 21, 2017

Sounds good in theory. The only reason we didn't do this at the time was because it wasn't needed, IIRC.

There are a couple of tricky things:

  • How do you want to handle non-strings? Currently in a CSP-restricted environment, eval(nonString) will throw. (I wonder if we have tests for that?) One refactoring would be to ensure things are a string before passing them to HostEnsureCanCompileStrings. If we do that, then behavior will change, and we'll bail out before ever hitting HostEnsureCanCompileStrings.
  • Similarly, for Function() and its various friends (GeneratorFunction(), AsyncFunction()), do we handle arg coercion before or after HostEnsureCanCompileStrings? This would change which error is thrown when doing e.g. Function({ toString() { throw 5; }).
  • For Function() and friends, what text should be passed? Should it be the body text of the function, which is directly passed as an argument? Or perhaps we should re-serialize the entire function, after we've assembled the various arguments to Function() into an actual function? The former would probably work for your purposes, although it's a bit weird to be doing checks on something that isn't standalone evaluatable source code. Maybe it would help if we named the new parameter something like sourceTextHint or proximateSourceText instead of just sourceText, with a reasonable explanation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment