Security issue. Found while reviewing the app for hosting many customers as one container per customer.
Problem
Dockerfile starts the app with CMD ["/app/rezervator", "-c /app/target/site/data/config.toml"].
src/main.rs serves the whole site root as static files: .service(Files::new("/", site_root)), and the site root is target/site.
So the configuration file is expected at target/site/data/config.toml, which is inside the static file root. Anything in target/site/data/ is reachable under /data/ (that is how /data/banner.css is loaded), so the config should be downloadable at /data/config.toml without authentication. It contains the database password, the session signing key and the SMTP credentials.
This follows from the code; it has not been tried against a running container yet.
With the session key an attacker can forge a session cookie for any user, including an admin.
Suggested fix
Read the config from a path outside the site root, e.g. /app/config/config.toml (mounted as a volume or a Docker secret), and update Dockerfile accordingly.
Keep target/site/data only for files that are meant to be public (banner image, generated CSS).
Consider allowing the secrets (database password, session key, SMTP password) to come from environment variables.
Existing deployments must rotate the session key and the database and SMTP passwords after the fix, since they may have been exposed.
Done when
GET /data/config.toml returns 404 in a container built from Dockerfile.
The app starts with the config mounted outside the site root.
README describes where the config file goes.
Security issue. Found while reviewing the app for hosting many customers as one container per customer.
## Problem
- `Dockerfile` starts the app with `CMD ["/app/rezervator", "-c /app/target/site/data/config.toml"]`.
- `src/main.rs` serves the whole site root as static files: `.service(Files::new("/", site_root))`, and the site root is `target/site`.
So the configuration file is expected at `target/site/data/config.toml`, which is inside the static file root. Anything in `target/site/data/` is reachable under `/data/` (that is how `/data/banner.css` is loaded), so the config should be downloadable at `/data/config.toml` without authentication. It contains the database password, the session signing key and the SMTP credentials.
This follows from the code; it has not been tried against a running container yet.
With the session key an attacker can forge a session cookie for any user, including an admin.
## Suggested fix
- Read the config from a path outside the site root, e.g. `/app/config/config.toml` (mounted as a volume or a Docker secret), and update `Dockerfile` accordingly.
- Keep `target/site/data` only for files that are meant to be public (banner image, generated CSS).
- Consider allowing the secrets (database password, session key, SMTP password) to come from environment variables.
- Existing deployments must rotate the session key and the database and SMTP passwords after the fix, since they may have been exposed.
## Done when
- `GET /data/config.toml` returns 404 in a container built from `Dockerfile`.
- The app starts with the config mounted outside the site root.
- README describes where the config file goes.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Security issue. Found while reviewing the app for hosting many customers as one container per customer.
Problem
Dockerfilestarts the app withCMD ["/app/rezervator", "-c /app/target/site/data/config.toml"].src/main.rsserves the whole site root as static files:.service(Files::new("/", site_root)), and the site root istarget/site.So the configuration file is expected at
target/site/data/config.toml, which is inside the static file root. Anything intarget/site/data/is reachable under/data/(that is how/data/banner.cssis loaded), so the config should be downloadable at/data/config.tomlwithout authentication. It contains the database password, the session signing key and the SMTP credentials.This follows from the code; it has not been tried against a running container yet.
With the session key an attacker can forge a session cookie for any user, including an admin.
Suggested fix
/app/config/config.toml(mounted as a volume or a Docker secret), and updateDockerfileaccordingly.target/site/dataonly for files that are meant to be public (banner image, generated CSS).Done when
GET /data/config.tomlreturns 404 in a container built fromDockerfile.