[x3d-public] script security

[Andreas Plesch]

On Thu, Oct 15, 2020 at 5: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 in 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.

Exactly, a script is not supposed to do anything outside its context,
like the parent html.

The problem is that this is quite difficult to enforce, certainly in a
web browser, when the script can execute arbitrary code. Javascript
executed by the engine in the web browser has access to everything on
the page (see my unsafe x3d script example in x_ite). This is why
Figma (linked earlier) decided to use another js engine for external
plugins rather than the browser's.

This is less of a problem in x3d browsers. They would typically use a
third party js engine which is designed for embedding. Still, there
has to be exchange between the js world and the outside world which
may be exploitable by bad scripts. For example, duktape has a long
page on how to do safe sandboxing, still saying sandboxing is in
development. Is it possible to detect an infinite loop in a script ?
It may be possible to crash Octaga or freeWrl or InstantPlayer with a
bad script.

x3dom's approach is inverted. Instead of having scripts in a scene, it
has scenes in scripts. The scripts use a directout approach, and
events get delivered to registered handlers. This is how javascript
works in html pages, and stays the concern of the web browser.

Anyways, it should be possible to implement some unsafe version of the
X3D Script node in x3dom. Use eval to get the functions in an
encapsulated function context. Anything outside the functions will
also get executed as it will be hard to sanitize the source text. Run
initialize. Use the set_xfield functions on field_changed (xfield).
Post messages for all _changed fields as given in the field def.
Somehow deal with SFNode fields.



> 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
> Sent: Thursday, October 15, 2020 1:33 PM
> To: Andreas Plesch
> Cc: X3D Graphics public mailing list
> 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
>
>



-- 
Andreas Plesch
Waltham, MA 02453