Bugzilla

We've effectively removed innerHTML-style XSS attacks on chrome from JS by passing all things through the sanitizer. In 68, we've done something similar with DTDs as well. We're working on removing eval() and similar untrusted JS on a per-script basis (bug 1473549). So we're gaining confidence in the trustworthiness of what we run in existing chrome:/resource:

One of the more recent sandbox escapes (cf. bug 1559845 / bug 1559858) has involved loading untrusted content as a separate window in the parent process. Obviously we're changing the IPC messages that let that happen, but I'd like to suggest that we do two things to combat that:

1. make the JS engine/loader code refuse to load scripts with non-chrome/resource: associated URIs in the parent process. (To be clear, this is a bit different from using CSP because CSP won't affect documents we don't ship, and because for historical reasons it's not straightforward to protect browser.xhtml and other shipped docs with CSP that includes unsafe-eval.)
2. refuse to load/construct documents with non-chrome/resource:/about: URIs in the parent process.

This will break data: URI'd scripts/windows in the parent, which might need some test changes (but hopefully not too many).

Ehsan, Bobby, do these ideas seem feasible? Any particular things to look out for in how we would execute on those ideas?

We've effectively removed innerHTML-style XSS attacks on chrome from JS by passing all things through the sanitizer. In 68, we've done something similar with DTDs as well. We're working on removing eval() and similar untrusted JS on a per-script basis (bug 1473549). So we're gaining confidence in the trustworthiness of what we run in existing chrome:/resource:

One of the more recent sandbox escapes (cf. bug 1559845 / bug 1559858) has involved loading untrusted content as a separate window in the parent process. Obviously we're changing the IPC messages that let that happen, but I'd like to suggest that we do two things to combat that:

1. make the JS engine/loader code refuse to load scripts with non-chrome/resource: associated URIs in the parent process. (To be clear, this is a bit different from using CSP because CSP won't affect documents we don't ship, and because for historical reasons it's not straightforward to protect browser.xhtml and other shipped docs with CSP that includes unsafe-eval.) (Edit: I've split this off to bug 1562221)
2. refuse to load/construct documents with non-chrome/resource:/about: URIs in the parent process.

This will break data: URI'd scripts/windows in the parent, which might need some test changes (but hopefully not too many).

Ehsan, Bobby, do these ideas seem feasible? Any particular things to look out for in how we would execute on those ideas?