[x3d-public] script security

Thu Oct 15 18:33:09 PDT 2020

I was mildly successful about sanitizing  code by splitting on function,
but yeah, still a problem.

On Thu, Oct 15, 2020 at 8:28 PM John Carlson <yottzumm at gmail.com> wrote:

>
>
> 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/d370aba0/attachment.html>