Private information on Glitch instances

Glitch Help
1

I’m working on some examples of remote execution just as an experiment where a remote user can essentially run arbitrary code on that glitch instance.

They could effectively nuke everything on the glitch, which is okay (the workflow is to load it from Github into a glitch and play around with it).

One thing I want to verify though is that any private information for a user won’t be leaked.

  1. Nothing will be placed in .env or .data, but are there any other files, directories, etc that are stored in a glitch instance that could contain private data?

  2. The access tokens for linking to Github are not stored in the actual glitch instance right?

  3. Are there any environment variables exposing sensitive data beyond what the .env enables?

Edit:
Looks like at least one to be aware of is that the PROJECT_INVITE_TOKEN is exposed in an instance

2

Hi Milan,

giving complete access on a Glitch project to a third party is something we didn’t consider; the owner of the project is responsible for the private information stored there, which include data in .env, .data (which are normal files and directories inside the /app directory in the project) and the PROJECT_INVITE_TOKEN.

We don’t store user information in the project though: a malicious user might be able (for example through the invite token) to acquire access to the project, but cannot impersonate other users.

If you are giving other people access to your project, make sure you secure all of your data and test it on a “demo remix” :slight_smile:

1 Like
3

Thank you for the reply etamponi!

Some more things from looking around a glitch:The git username and email use the name System and no email is provided so that seems to not reveal anything private.

The .bash_history file does exist if you use the web console interface, so that’s something to be aware of.

Other than that it looks pretty good as far as I can tell.

It would be nice to be able to turn on or off exposing the PROJECT_INVITE_TOKEN in a setting outside the container. Should I make a separate post as a feature request for that?

Sounds like the best approach for having users play with the example that can end up running arbitrary code is:

  1. Don’t host Glitch instance for users to target directly on my account.
  2. In the Github project encourage users to Remix on Glitch from Github
  3. Suggest that users delete the Glitch when they are done experimenting

This seems like another good use case for having an anonymous glitch remix like mentioned here: Show logs without remixing

4

Sorry for the late response!

I assume you are giving other users access to the project through a web interface that you own, so that foreign code is spawned by code that you can control. If this is the case, you can just remove PROJECT_INVITE_TOKEN from the environment in which the foreign code runs.

As for .bash_history, you can make sure it is removed before the foreign code runs.

We added the feature “safely run foreign code in containers” to our backlog, but it’s not a priority right now so we can’t give you an estimate of when/if it will be delivered :slight_smile: I hope my suggestions help you in the meantime!

1 Like