Pluto.jl: Implement authentication token

[garrison]

When Pluto.jl is started with the recommended configuration, it says:

Go to http://localhost:1234/ to start writing ~ have fun!

This implies that any other user or program on my machine can connect to port 1234 and execute arbitrary code with my user privileges. How fun! :wink:

Jupyter's page on Security in the Jupyter notebook server says:

Since access to the Jupyter notebook server means access to running arbitrary code, it is important to restrict access to the notebook server. For this reason, notebook 4.3 introduces token-based authentication that is on by default.

Thus, I suggest that Pluto.jl should also have token authentication.

[fonsp]

Could you say a bit more about the other user or program? If they are malicious, hasn't the security breach already happened?

[garrison]

It could be another user on the same machine that does not have the privileges that I do. Think, for instance, of the head node of a cluster with multiple users. If a user is using Pluto.jl on that node, any other user of the cluster can execute code as that user.

In general, security is a multi-layered process. Even on a single user machine, it is a poor practice to open up localhost to arbitrary code execution.

[fonsp]

Thanks for bringing it up - we have started working on a fix.

[lungben]

If you are using Pluto in a Docker container, this is less of a concern.

On the other hand, it may be difficult for the user to get the token information from the Docker host. Therefore it would be good to have the possibility to pre-define the token on the server side, preferably with an environment variable.

[fonsp]

There will be the option to disable tokens, intended for setups that are already secure (like binder)

[fonsp]

Added to Pluto 0.12.0:

https://github.com/fonsp/Pluto.jl/pull/529

For more info, see ?Pluto.Configuration.SecurityOptions: https://github.com/fonsp/Pluto.jl/pull/529/files#diff-ed0c4ead6095fff7f4d3d64994b92f4eR21-R44

[fonsp]

If there are no bad people logged in on the same system, like in the Docker setup that @lungben mentioned, then it can be disabled using:

Pluto.run(require_secret_for_access=true)

This alternative setup will still use a secret cookie for authentication, but the secret cookie is automatically set when your browser visits / or /edit. The cookie has property SameSite: Strict, and the / and /edit endpoints are protected by CORS policy, so this setup is still protected against XSS.