[x3d-public] script security

[John Carlson]

Joe, I think eval has some way of handling these contexts from my reading
of X_ITE, but I didn’t really understand.  In JavaScript, functions create
new contexts.

On Thu, Oct 15, 2020 at 4:29 PM Joseph D Williams <joedwil at earthlink.net>
wrote:

>
>    - Of course, this concern exists for any html page loaded into a
>    browser. The difference with x3d is that the code is more hidden,
>    perhaps in an inline, and not expected to do anything outside the x3d
>    scene.
>
>
>
> The script is expected to  be active only it the context in which it is an
> instance.
>
> A scene creates the main context, then, an inline or a proto instance must
> create a new child context then use organized import/export and is code to
> communicate with its parent scene context.
>
> Why would I expect that a script in my scene or an inline or a proto I
> might use would be able to interact with a parent html context except using
> x3d SAI? That is like me thinking a script in any parent context could talk
> to my scene using anything else than x3d SAI.
>
> With SAI, my scene knows how to handle its parent context and child
> contexts just fine.
>
> At least that’s the way I learned it.
>
> Thanks,
>
> Joe
>
>
>
>
>
>
>
>
>
> *From: *John Carlson <yottzumm at gmail.com>
> *Sent: *Thursday, October 15, 2020 1:33 PM
> *To: *Andreas Plesch <andreasplesch at gmail.com>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] script security
>
>
>
> This may be worth looking at:
>
>
>
> https://github.com/google/caja
>
>
>
>
>
> On Thu, Oct 15, 2020 at 3:07 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
> Since scripts run arbitrary javascript code and javascript has access
> to everything in a browser sandbox, or, outside the context of a web
> browser, potentially to the operating system, there are security
> implications to the x3d script node.
>
> It is easy for a bad actor to construct a x3d scene which has
> disruptive code. Here is an example with x_ite:
>
> xml:
> https://gist.github.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d
>
> live:
> regular script:
>
> https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/safe.html
>
> unsafe script:
>
> https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/unsafe.html
>
> Of course, this concern exists for any html page loaded into a
> browser. The difference with x3d is that the code is more hidden,
> perhaps in an inline, and not expected to do anything outside the x3d
> scene.
>
> Here is an interesting read:
> https://www.figma.com/blog/how-we-built-the-figma-plugin-system/
>
> Their solution in the end was:
> https://www.figma.com/blog/an-update-on-plugin-security/
>
> They decided to run a whole new javascript engine (quickjs) compiled
> to wasm inside the browser. This is similar to how standalone x3d
> browsers embed js engines like duktape. Such browsers then need to
> rely on the security of the embedded engines.
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201015/4e3dff30/attachment.html>