[x3d-public] script security

[Joseph D Williams]

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

Right, I should list scene, inline, proto, and script as creating new context. 
Any others? 
If the script functionality is some sort of add on to the x3d browser then that engine has to keep track of each x3d script context(s) it is working on. For ecmascript, if whatever js engine is an accessory whatever js engine, or if it is ‘built-in’ as for a standalone or a plug-in implementing the SAI, is supposed to understand context very well and never mess up. 
Thanks,
Joe





From: John Carlson
Sent: Thursday, October 15, 2020 2:35 PM
To: Joseph D Williams
Cc: Andreas Plesch; X3D Graphics public mailing list
Subject: Re: [x3d-public] script security

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