<div dir="auto">I was mildly successful about sanitizing  code by splitting on function, but yeah, still a problem.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 8:28 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 7:56 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">On Thu, Oct 15, 2020 at 5:29 PM Joseph D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>> wrote:<br>
><br>
> Of course, this concern exists for any html page loaded into a<br>
> browser. The difference with x3d is that the code is more hidden,<br>
> perhaps in an inline, and not expected to do anything outside the x3d<br>
> scene.<br>
><br>
> The script is expected to  be active only in the context in which it is an instance.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
Exactly, a script is not supposed to do anything outside its context,<br>
like the parent html.<br>
<br>
The problem is that this is quite difficult to enforce, certainly in a<br>
web browser, when the script can execute arbitrary code. Javascript<br>
executed by the engine in the web browser has access to everything on<br>
the page (see my unsafe x3d script example in x_ite). This is why<br>
Figma (linked earlier) decided to use another js engine for external<br>
plugins rather than the browser's.</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">It may be worth sending your unsafe script through Caja just to test.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
This is less of a problem in x3d browsers. They would typically use a<br>
third party js engine which is designed for embedding. Still, there<br>
has to be exchange between the js world and the outside world which<br>
may be exploitable by bad scripts. For example, duktape has a long<br>
page on how to do safe sandboxing, still saying sandboxing is in<br>
development. Is it possible to detect an infinite loop in a script ?<br>
It may be possible to crash Octaga or freeWrl or InstantPlayer with a<br>
bad script.<br>
<br>
x3dom's approach is inverted. Instead of having scripts in a scene, it<br>
has scenes in scripts. The scripts use a directout approach, and<br>
events get delivered to registered handlers. This is how javascript<br>
works in html pages, and stays the concern of the web browser.<br>
<br>
Anyways, it should be possible to implement some unsafe version of the<br>
X3D Script node in x3dom. Use eval to get the functions in an<br>
encapsulated function context.</blockquote><div dir="auto"><br></div><div dir="auto">I used new Function instead of eval on Leonard’s advice.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">Anything outside the functions will<br>
also get executed as it will be hard to sanitize the source text. Run<br>
initialize.</blockquote><div dir="auto"><br></div><div dir="auto">I am right here with X3DScript except for field variable declarations.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"> Use the set_xfield functions on field_changed (xfield).</blockquote><div dir="auto"><br></div><div dir="auto">Not implemented.  Is this new code?   Where would I put it under Scripting/?   Can you provide a short example?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
Post messages for all _changed fields as given in the field def.<br>
Somehow deal with SFNode fields.</blockquote><div dir="auto"><br></div><div dir="auto">Examples welcome!</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
</blockquote><div dir="auto"><br></div><div dir="auto">What a about ROUTEs?   How do we deal with script tags in HTML versus XML?</div></div></div><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
<br>
> With SAI, my scene knows how to handle its parent context and child contexts just fine.<br>
><br>
> At least that’s the way I learned it.<br>
><br>
> Thanks,<br>
><br>
> Joe<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> From: John Carlson<br>
> Sent: Thursday, October 15, 2020 1:33 PM<br>
> To: Andreas Plesch<br>
> Cc: X3D Graphics public mailing list<br>
> Subject: Re: [x3d-public] script security<br>
><br>
><br>
><br>
> This may be worth looking at:<br>
><br>
><br>
><br>
> <a href="https://github.com/google/caja" rel="noreferrer" target="_blank">https://github.com/google/caja</a><br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Oct 15, 2020 at 3:07 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> Since scripts run arbitrary javascript code and javascript has access<br>
> to everything in a browser sandbox, or, outside the context of a web<br>
> browser, potentially to the operating system, there are security<br>
> implications to the x3d script node.<br>
><br>
> It is easy for a bad actor to construct a x3d scene which has<br>
> disruptive code. Here is an example with x_ite:<br>
><br>
> xml: <a href="https://gist.github.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d" rel="noreferrer" target="_blank">https://gist.github.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d</a><br>
><br>
> live:<br>
> regular script:<br>
> <a href="https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/safe.html" rel="noreferrer" target="_blank">https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/safe.html</a><br>
><br>
> unsafe script:<br>
> <a href="https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/unsafe.html" rel="noreferrer" target="_blank">https://gist.githack.com/andreasplesch/8ded7b7ffb598a63c44318f5810b260d/raw/63c673c9bc177c9ad64a3e5a1ad9bd6f7180921a/unsafe.html</a><br>
><br>
> Of course, this concern exists for any html page loaded into a<br>
> browser. The difference with x3d is that the code is more hidden,<br>
> perhaps in an inline, and not expected to do anything outside the x3d<br>
> scene.<br>
><br>
> Here is an interesting read:<br>
> <a href="https://www.figma.com/blog/how-we-built-the-figma-plugin-system/" rel="noreferrer" target="_blank">https://www.figma.com/blog/how-we-built-the-figma-plugin-system/</a><br>
><br>
> Their solution in the end was:<br>
> <a href="https://www.figma.com/blog/an-update-on-plugin-security/" rel="noreferrer" target="_blank">https://www.figma.com/blog/an-update-on-plugin-security/</a><br>
><br>
> They decided to run a whole new javascript engine (quickjs) compiled<br>
> to wasm inside the browser. This is similar to how standalone x3d<br>
> browsers embed js engines like duktape. Such browsers then need to<br>
> rely on the security of the embedded engines.<br>
><br>
> --<br>
> Andreas Plesch<br>
> Waltham, MA 02453<br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
><br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div></div>
</blockquote></div></div>