JavaScript playground

yoursunny

I want to establish a small web-based JavaScript playground, similar to https://codesandbox.io/ and https://npm.runkit.com/ . The existing services are unsuitable because they either use old version of Node or lack support of ES Modules. The purpose is to give users a way to quickly try out some JavaScript libraries that I authored, without installing them first.

The intended user experience is:
1. User opens webpage.
2. User types in JavaScript or TypeScript code that uses my libraries. Ideally, the code editor should support auto-completion.
3. The server side runs Webpack to bundle their code.
4. User can open a webpage to execute their code.
5. Note: server side only executes Webpack; user cannot execute arbitrary code on the server.

I have a bunch of 2~4GB KVM and VZ7 servers.
I can limit CPU usage by queuing Webpack requests and running one build at a time.
I plan to run Webpack inside Docker container as a non-root user, to reduce hacking risk.
I plan to serve bundled code under a separate domain, to avoid exposing cookies of the main site.
What else could go wrong?

ionswitch_stan

I would consider firewalling the containers such that they cannot access external resources (ie, be used to send spam or L7 ddos).

evnix

@yoursunny said: 5. Note: server side only executes Webpack; user cannot execute arbitrary code on the server.

You can do really nasty stuff with just webpack code but docker should solve that issue for you.

I had seen a playground where webpack(I can't remember the name) was run directly on the browser,
I was curious to see what was going on, it seemed to use some kind of web assembly + some JS based virtual file system.

The initial load took a few good seconds and after that it was really smooth and since I have a really good machine with an i9 CPU, the experience was faster and better than the ones that compiled everything on the server side.

This depends, Most devs you would target with your libraries may or may not have beefy machines.

Probably some kind of way to detect and offload slow machines on to your VPSes

yoursunny

@evnix said:
You can do really nasty stuff with just webpack code but docker should solve that issue for you.

How to do nasty stuff with Webpack? If Webpack config cannot be changed, user can't execute arbitrary code on the server, right?

evnix

@yoursunny said:

@evnix said:
You can do really nasty stuff with just webpack code but docker should solve that issue for you.

How to do nasty stuff with Webpack? If Webpack config cannot be changed, user can't execute arbitrary code on the server, right?

Yeah if you don't allow them to execute or include any foreign code in webpack config and the main json file, you should be safe at least that is what I believe.

yoursunny

@evnix said:
foreign code in the main json file

Bingo. If I allow editing package.json, one could import a package in which the post-install script contains malicious code, which will be executed on the server. Locking package.json, on the other hand, would severely limit the usefulness of a playground.

I'll have to think how to run Webpack in the browser. It's a safer route.

FAT32

Can you give a few examples what CodeSandbox and/or RunKit doesn't support? It works most of the time for me.

Daniel

@yoursunny said: If I allow editing package.json, one could import a package in which the post-install script contains malicious code, which will be executed on the server.

Not allowing importing npm packages really limits the usefulness though. One of the primary benefits of CodeSandbox is that you can import third party packages and modify the Webpack config (or use something other than Webpack, like Parcel).

yoursunny

@FAT32 said:
Can you give a few examples what CodeSandbox and/or RunKit doesn't support? It works most of the time for me.

CodeSandbox uses Node 10. I need Node 12.

RunKit does not support:

• import ES Modules.
• "nightly builds" from GitHub or tarball.
• TypeScript.

FAT32

@yoursunny said:
CodeSandbox uses Node 10. I need Node 12.

I see. In my opinion it is still working fantastic without Node 12 at this moment. I wonder if it is worth the time to build another playground because CodeSandbox is mature enough in my opinion and handled most of the important cases such as allow importing any npm packages.

About your concern on postinstall, maybe you can just ignore all scripts but there might be other consequences. Or you can fork npm and do some whitelisting.

gks

quickly try out some JavaScript libraries -- perhaps you need to block the ports, access to file system while running inside dockers. Webpack primarily authored for Browsers to substitute common-js, now heavily used for build tools. Someone can with a finite for loop to spike CPU, or create object to spike v8 memories or use dynamic import https://caniuse.com/#feat=es6-module-dynamic-import import function for code injection if not just eval.

Check stackblitz too.

vimalware

Building a sandbox for anyone to execute code?

I see nothing but pain headed your way.

Provide some other heavily input-sanitized service.