Censoring mechanism for import using escape sequences

[Ricardo Iván Vieitez Parra]

Hi,

I'm new to this list. My name is Ricardo Vieitez and I joined because of
my interest in security applications and JS security and isolation
mechanisms.

After a brief discussion with Kris from Agoric, I thought of a censoring
mechanism for the `import` keyword that at first glance seemed to come
with few downsides, namely replacing it totally or partially with an
appropriate unicode escape sequence, e.g., `\u0069mport` or
`i\u006dport`, and he suggested I share the technique here.

This works because, while unicode sequences are legal syntax as part of
identifiers [1], they're not legal syntax for keywords or reserved
words. Therefore, it can effectively block `import` expressions in all
of its forms without many negative consequences or altered behaviour in
the rest of the code.

For example, all of the following work equivalently:

* `({ imp\u006frt() { console.log('Hi') } }).import()`
* `({ imp\u006frt() { console.log('Hi') } }).imp\u006frt()`
* `({ import() { console.log('Hi') } }).import()`
* `({ ['imp\u006frt']() { console.log('Hi') } }).import()`
* `({ ['imp\u006frt']: ()=>{ console.log('Hi') } }).import()`
* `console.log({ ['imp\u006frt']: 'Hi' }.import)`
* `console.log({ 'imp\u006frt': 'Hi' }.import)`
* `console.log({ imp\u006frt: 'Hi' }.import)`
* `console.log(JSON.parse('{ "imp\u006frt": "Hi" }').import)`
* <console.log({ [`imp\u006frt`]: 'Hi' }.import)> (note: see
discussion below regarding templates)
* etc.

Whereas, `imp\u006frt('data:text/javascript,console.log("Hi")')` is
blocked as expected as a syntax error.

We discussed this approach yesterday at the weekly Endo meeting, and it
seems like it, however, has two main downsides that unfortunately make
it not work as generally as would be ideal for preventing the use of
import statements without parsing.

* The first downside is that it affects comments and source maps. This
is likely a minor inconvenience that can relatively easily be worked
around.
* The second and more critical downside is that it affects template
strings, and this doesn't seem to be possible to avoid without
parsing. For example, the following does _NOT_ work:

console.log({ [String.raw`imp\u006frt`]: 'Hi' }.import)

The second downside means that, in general, a simple S&R will not work
without possibly breaking some code.

Still, with these downsides I think that it may have some applications
for censoring in situations where there are no template strings, or it
can at least perhaps simplify censorship to reduce it to identifying
templates to leave them untouched.

Do you think this has potential?

Cheers,

--
Ricardo

[1] <https://262.ecma-international.org/5.1/#sec-7.6>

[Jordan Harband]

I'm confused why you'd ever be able to omit parsing; a string (at least one not used as a property) or comment with `import` in it shouldn't be altered, and without parsing you can't reliably figure that out.

--
You received this message because you are subscribed to the Google Groups "SES-strategy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ses-strategy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ses-strategy/3500a277-2d7b-c08a-c32b-ea56db92079e%40exactrealty.co.uk.