Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sandbox #7

Closed
TodePond opened this issue Jan 1, 2025 · 5 comments · Fixed by #34
Closed

Sandbox #7

TodePond opened this issue Jan 1, 2025 · 5 comments · Fixed by #34

Comments

@TodePond
Copy link
Collaborator

TodePond commented Jan 1, 2025

Is the code run in a sandbox? We should probably do some basic sandboxing like todepond.cool does

@felixroos
Copy link
Collaborator

felixroos commented Jan 1, 2025

not yet. we probably need it anway to avoid global scope naming collisions when adding hydra (shape / speed for example). on flok.cc, each language runs in an iframe afaik

edit: what i mean by global scope naming collisions: when the user code is evaluated, the referenced functions are made available on the window. if 2 languages have overlap, only one language can win, so the other looses that variable

@TodePond
Copy link
Collaborator Author

TodePond commented Jan 1, 2025

on flok.cc, each language runs in an iframe afaik

yes, though (intentionally) not a very sandboxed one. on todepond.cool i make it more restricted as its intended for random strangers to come in (eg: preventing networking), and i manually remove some global functions like alert to stop some easy forms of vandalism

@munshkr
Copy link

munshkr commented Jan 3, 2025

yes, though (intentionally) not a very sandboxed one. on todepond.cool i make it more restricted as its intended for random strangers to come in (eg: preventing networking), and i manually remove some global functions like alert to stop some easy forms of vandalism

That's interesting! Maybe Flok should also have those protection mechanisms by default, and in any case maybe add an option for the user to disable them in case they need those features?

@TodePond
Copy link
Collaborator Author

TodePond commented Jan 3, 2025

looking back at my code, I think I was able to get rid of the injected alert-blocking stuff after setting the right sandbox options:

<iframe
    sandbox="allow-scripts allow-same-origin allow-forms"
    src="https://flok.cc/s/pastagang">
  </iframe>

the only time it's been a problem is when someone wants to import some external library or something.

the things I'm worried about are:

  • cross-site-scripting (i was originally hosting the flok iframe on my own site where i have passwords and admin controls etc)
  • networking to connect users to some unknown bad purposes. eg: spamming, DOS, mining, whatever. i know it's a long shot but I'd rather not risk it.

so sandboxing, and moving it to a separate domain worked pretty well for these i think

@TodePond
Copy link
Collaborator Author

TodePond commented Jan 4, 2025

Fixed with #34!

If we add a web-only in flok, eg: munshkr/flok#315, it might be worth doing the same for that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants