[x3d-public] script security

[John Carlson]

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