[x3d-public] script security

[Joseph D Williams]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201015/1e934efc/attachment-0001.html>