Commit Graph

7 Commits

Author SHA1 Message Date
Leslie H
24ce54b586
Improve session ID security (#1059)
Follow-up of #994. This PR revises the session ID generation logic to improve security in the absence of a secure session secret. It also adds a section in the admin panel "security" section to nag system admins when GRIST_SESSION_SECRET is not set.

Following is an excerpt from internal conversation.

TL;DR: Grist's current implementation generates semi-secure session IDs and uses a publicly known default signing key to sign them when the environment variable GRIST_SESSION_SECRET is not set. This PR generates cryptographically secure session IDs to dismiss security concerns around an insecure signing key, and encourages system admins to configure their own signing key anyway.

> The session secret is required by expressjs/session to sign its session IDs. It's designed as an extra protection against session hijacking by randomly guessing session IDs and hitting a valid one. While it is easy to encourage users to set a distinct session secret, this is unnecessary if session IDs are generated in a cryptographically secure way. As of now Grist uses version 4 UUIDs as session IDs (see app/server/lib/gristSessions.ts - it uses shortUUID.generate which invokes uuid.v4 under the hood). These contain 122 bits of entropy, technically insufficient to be considered cryptographically secure. In practice, this is never considered a real vulnerability. To compare, RSA2048 is still very commonly used in web servers, yet it only has 112 bits of security (>=128 bits = "secure", rule of thumb in cryptography). But for peace of mind I propose using crypto.getRandomValues to generate real 128-bit random values. This should render session ID signing unnecessary and hence dismiss security concerns around an insecure signing key.
2024-06-25 15:43:25 -04:00
Jordi Gutiérrez Hermoso
c3e23ca81e admin: fix warning in websocket probe
This is a small thing, but when visiting the admin, the websocket test
doesn't send valid JSON, which the receiving endpoint expects. This
results in a harmless exception being thrown.

While this test should eventually be modified to be run from the
frontend, for now let's just make a small fix and send valid JSON in
order to avoid that JSON parsing exception.
2024-06-06 18:25:27 -04:00
Paul Fitzpatrick
5dc4706dc7
reconcile boot and admin pages further (#963)
This adds some remaining parts of the boot page to the admin panel, and then removes the boot page.
2024-05-23 16:40:31 -04:00
Spoffy
b4acb157f8
Displays the current authentication mechanism in the admin panel (#981)
* Adds authentication mechanism to admin panel

Adds field to the "Security settings" admin display, showing the
currently configured authentication mechanism.

* Adds 14px margin to admin panel names
2024-05-16 18:09:38 +01:00
Florent
5e3cd94177
Introduce APP_HOME_INTERNAL_URL and fix duplicate docs (#915)
Context:

On self-hosted instances, some places in the code rely on the fact that we resolves public domains while being behind reverse proxies. This leads to cases where features are not available, such as the "Duplicate document" one.

Bugs that are solved - n self-hosted instances:

Impossible to open templates and tutorials right after having converted them;
Impossible to submit forms since version 1.1.13;
Impossible to restore a previous version of a document (snapshot);
Impossible to copy a document;

Solution:

Introduce the APP_HOME_INTERNAL_URL env variable, which is quite the same as APP_DOC_INTERNAL_URL except that it may point to any home worker;
Make /api/worker/:assignmentId([^/]+)/?* return not only the doc worker public url but also the internal one, and adapt the call points like fetchDocs;
Ensure that the home and doc worker internal urls are trusted by trustOrigin;

---------

Co-authored-by: jordigh <jordigh@octave.org>
2024-05-14 12:58:41 -04:00
Paul Fitzpatrick
d431c1eb63 (core) add a sandbox check to admin panel, and start reconciling boot and admin pages
Summary:
This adds a basic sandbox check to the admin panel. It also makes
the "probes" used in the boot page available from the admin panel,
though they are not yet displayed. The sandbox check is built as
a probe.

In the interests of time, a lot of steps had to be deferred:
 * Reconcile fully the admin panel and boot page. Specifically, the
   admin panel should be equally robust to common configuration problems.
 * Add tests for the sandbox check.
 * Generalize to multi-server setups. The read-out will not yet be useful
   for setups where doc workers and home servers are configured
   separately.

Test Plan: Added new test

Reviewers: jarek, georgegevoian

Reviewed By: georgegevoian

Differential Revision: https://phab.getgrist.com/D4241
2024-04-29 20:52:39 -04:00
Paul Fitzpatrick
95b734149e
make a /boot/GRIST_BOOT_KEY page for diagnosing configuration problems (#850)
This is a start at a page for diagnosing problems while setting up Grist. Starting to add some diagnostics based on feedback in github issues. We should make Grist installation easier! But when there is a problem it should be easier to diagnose than it is now, and this may help. The page is ugly and doesn't have many diagnostics yet, but we can iterate.

Visit `/boot` on a Grist server for tips on how to use this feature.
2024-03-04 16:22:47 -05:00