<div dir="auto">This is also good reading:</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html</a></div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 3:32 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 dir="auto">This may be worth looking at:</div><div dir="auto"><br></div><div><a href="https://github.com/google/caja" target="_blank">https://github.com/google/caja</a></div><div dir="auto"><br></div><div><br><div class="gmail_quote"></div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></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)">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>
</blockquote></div></div>
</blockquote></div></div>