[x3d-public] script security

[John Carlson]

On Thu, Oct 15, 2020 at 7:56 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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.



It may be worth sending your unsafe script through Caja just to test.


>
> 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.


I used new Function instead of eval on Leonard’s advice.

Anything outside the functions will
> also get executed as it will be hard to sanitize the source text. Run
> initialize.


I am right here with X3DScript except for field variable declarations.

> Use the set_xfield functions on field_changed (xfield).


Not implemented.  Is this new code?   Where would I put it under
Scripting/?   Can you provide a short example?

>
> Post messages for all _changed fields as given in the field def.
> Somehow deal with SFNode fields.


Examples welcome!


>
What a about ROUTEs?   How do we deal with script tags in HTML versus XML?


>
>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201015/91e227c4/attachment-0001.html>