Playground Security Considerations

Hi Babylonjs Team,

How secure is following a playground link that someone sent me? How does the babylonjs website prevent bad actors from embedding malicious code in a playground and affecting me whenever I execute / open it?

Thanks,

-Thomas

This is as dangerous as opening any jsfiddle or online code editor. The only thing we could do is adding a flag to prevent running until the play button has been pressed :frowning:

Thank you for the info!

until before There was certainly no offensive code
There is no one, but I have a malicious mind, but I think it can be dangerous enough.
Convenience to autorun is very good but It would be sad if it allowed me to do a malicious attack

On the bright side the web site does not have any info to stole or credentials :slight_smile:

So it is not worse than any link you open as any attacks you can do here could be hosted on any other websites.

I guess having a autorun option ppl could turn on/off would be cool enough @RaananW any thoughts ?

Yeah, I have been thinking about this issue for quite some time.
First, a few thoughts about it - a browser is a sandboxed environment. When opening a website, this website can access resources only this website is able to read, i.e. resources created by and for this website. I can’t access cookies made for other sites (like, for example, your google credentials or something like that). It is true for any other website. as @sebavan mentioned, this is the same as a jsfiddle or a benchmark testing. It will run automatically. Just as much as you wouldn’t open a link from an untrusted source, you shouldn’t open a random playground that was anonymously sent to you :slight_smile:
This can be said about any other website that lets you run code, of course. It’s always an issue. However, the one thing we don’t do on the playground is store any type of cookies (that we control). There is no login, there is little to no external information linked to it, so the only thing someone might be able to do it make your computer do work that you don’t really want (like mining cryptos, but they dropped like 23789%, so they won’t even bother :slight_smile: ). Another thing a good hacker might do is use a 0-day security issue on your browser. But again, this goes to any other website. One last thing someone might do is fingerprinting - like running analytics on people visiting a certain playground. That’s annoying, and certainly is a privacy issue, but there is little to no security issue involved here.

Auto-run on/off will work. Of course. BUT the default, in that case, must be off, right? because people who don’t know our playground have not yet defined the auto-run definition. That will hurt the playground’s experience badly. Similar to how audio requires you to click something to start working, we will ask for the user to give consent to run a playground. Not the best UX in the world. and besides, how will you really know if you can run it or not? If you use the frame.html endpoint you don’t really see the code. if you use the playground you can see the code, but trust me - if someone added some weird code, it will certainly be obfuscated or hidden in some clever way.

TL;dr - that’s a very hard topic to tackle. But your browser sandbox protects you. we can’t prevent anyone from storing malicious code in the playground. We can (and are!) monitoring high-traffic playgrounds to be sure that they don’t have any issues with them (mainly to be sure the playground is running TBH).

I hope that makes sense!

3 Likes

Yup I would not turn it off by defaut, more something the user has to opt-in so they could opt in from the defaut pg which is safe. And then on frame s and such it would require a nice message: “Are you sure, Are you really sure ???” With a link to the pg to look at the code. Or simply a link to the playground.

Obfuscated code and the like of it with external scripts would be users responsibly to eye ball.

That said we all run npm with gazillions of dependencies or install browsers and vscode extensions which have a way higher potential to be harmful. It is definitely not a valid excuse but I love the risk, it feels like extreme sports :wink:

2 Likes

Agree this is a difficult problem to tackle and UX should not suffer, but there are some (easy-ish) things you can do to protect users and improve UX. For example, the below code snippet redirects the user:

var createScene = function () {
    document.location.href = "https://example.com/";
};

One holistic approach you could take is to render the scene in a “srcDoc” sandboxed iframe (disallowing things like forms / popups) on the same domain, so that things like the above code example will only redirect the iframe’s view, instead of the entire window. That would improve UX, because things like popups, forms, whole screen redirects would be eliminated or at least contained in an iframe.

It may also be problematic that https://playground.babylonjs.com is a subdomain of .babylonjs.com, in which case if new cookies are introduced to babylonjs.com, they could be exposed to the playground.

I don’t think this is critical work, but rather a nit-pick that is worth being explored.

That’s already much better than dropbox or adobe :grin:

Agreed! And then, all of us here are either devs or related to dev and on the bright side of the force :crossed_swords: :angel:
So, I say ‘let them come’ if they dare. We’ll turn’em into tiny little pieces and have’em explode into space :milky_way: :boom: The faen bastards.