mirror of
https://github.com/plankanban/planka.git
synced 2026-08-31 01:13:20 +08:00
de4d768831
Reported against 2.2.1 by someone reading the source. Every finding held. **Sign-in had no ceiling.** Failures were logged with the caller's address and nothing more. Two counters now — one per address, one per account — because the two attacks look different: one source working through many accounts is caught by the first, many sources working on one account by the second, and behind a proxy only the second still means anything. The count is kept in the process that serves the request. PLANKA needs no Redis and the stock deployment is one container; run several and each keeps its own count, which multiplies the ceiling by their number. That trade is written where the limits are configured. **The second factor could be guessed at leisure.** Six digits, and a pending token that stayed valid for its full ten minutes however many codes were wrong. Wrong codes are now counted on the session row — in the database, so the count survives a restart and holds across every process — and when the budget is spent the session is destroyed. After that even the right code is refused and the login starts over from the password. **Avatars, background images and favicons** checked the token's signature and nothing else, so a revoked session, a deactivated account or a changed password all kept working there for as long as the signature lasted, which is a year by default. The five checks the API makes now live in one helper that both use, rather than the shortened copy that had drifted from it. **A link attachment's favicon** was fetched from wherever the URL pointed. Storing a link is harmless — it is a string the user typed — but fetching its icon is a request the server makes to an address the user chose, and whether an icon came back reported on what is reachable from inside the network. Server-side fetches now refuse private, loopback and link-local addresses, `169.254.169.254` among them. The attachment is still created: linking to an internal wiki is a legitimate thing to do, and it was the server's own request that had to stop. **The signing key.** Our own compose file ships `notsecretkey`, and it is printed in the documentation — so on any instance that copied it, anyone can sign a token for any account. PLANKA now says so on every start, and keeps saying it, along with a key that is missing or shorter than 32 characters. The placeholder carries the warning inline, where it is copied from. **The backup script** wrote password hashes, live sessions, TOTP secrets and SMTP credentials to an unencrypted archive. `BACKUP_PASSPHRASE` now encrypts it, and without one the script says what it just put on disk. It also says what it is — an example for the stock compose stack, not a backup concept — and names the window between the database dump and the file copy, which no ordering closes.
97 lines
3.5 KiB
Bash
97 lines
3.5 KiB
Bash
#!/bin/bash
|
|
#
|
|
# An EXAMPLE, for the stock docker-compose stack and nothing else. It is not a
|
|
# backup concept, and PLANKA does not ship one: what has to be preserved depends
|
|
# on how you run it. On k3s with S3-backed uploads and a managed database
|
|
# cluster this script protects nothing — your object store and your database
|
|
# have their own answers, and those are the ones that count.
|
|
#
|
|
# Two things to know before relying on it:
|
|
#
|
|
# 1. The archive is written in the clear unless you set BACKUP_PASSPHRASE. It
|
|
# contains the whole database: password hashes, active sessions, TOTP
|
|
# secrets and recovery codes, SMTP credentials and any API keys. Treat an
|
|
# unencrypted archive as equivalent to shell access on the instance.
|
|
#
|
|
# 2. It runs against a live instance, so the database and the uploaded files
|
|
# are captured moments apart. The database goes first on purpose: something
|
|
# created in between leaves a file with no row, which is inert. The other
|
|
# order would leave rows pointing at files that were never copied. Neither
|
|
# order survives a deletion landing in the gap. For a backup with no such
|
|
# window, stop the app for the duration, or use your database's
|
|
# point-in-time recovery together with a volume snapshot.
|
|
#
|
|
# Usage:
|
|
# ./docker-backup.sh [target-directory]
|
|
# BACKUP_PASSPHRASE='…' ./docker-backup.sh [target-directory]
|
|
|
|
# Stop on error
|
|
set -e
|
|
|
|
# Configure those to match your Docker container names
|
|
DOCKER_CONTAINER_POSTGRES="planka-postgres-1"
|
|
DOCKER_CONTAINER_PLANKA="planka-planka-1"
|
|
|
|
# Use provided directory or default to current directory
|
|
BACKUP_DIR="${1:-$(pwd)}"
|
|
|
|
if [ -z "$1" ]; then
|
|
echo "No backup directory specified, backing up to current directory: $BACKUP_DIR"
|
|
else
|
|
echo "Backing up to: $BACKUP_DIR"
|
|
fi
|
|
echo
|
|
|
|
if date --version >/dev/null 2>&1; then
|
|
# GNU date (Linux)
|
|
BACKUP_DATETIME=$(date --utc +%FT%H-%M-%SZ)
|
|
else
|
|
# BSD date (macOS)
|
|
BACKUP_DATETIME=$(date -u +%FT%H-%M-%SZ)
|
|
fi
|
|
|
|
BACKUP_TEMP="$BACKUP_DIR/$BACKUP_DATETIME-backup"
|
|
|
|
# Create temporary directory
|
|
mkdir -p "$BACKUP_TEMP"
|
|
|
|
echo -n "Exporting postgres database ... "
|
|
docker exec -t "$DOCKER_CONTAINER_POSTGRES" pg_dumpall -c -U postgres > "$BACKUP_TEMP/postgres.sql"
|
|
echo "Success!"
|
|
echo
|
|
|
|
echo -n "Exporting data volume ... "
|
|
docker run --rm --volumes-from "$DOCKER_CONTAINER_PLANKA" -v "$BACKUP_TEMP:/backup" node:24-alpine cp -r /app/data /backup/data
|
|
echo "Success!"
|
|
echo
|
|
|
|
if [ -n "$BACKUP_PASSPHRASE" ]; then
|
|
echo -n "Creating encrypted archive $BACKUP_DATETIME-backup.tgz.enc ... "
|
|
tar -C "$BACKUP_DIR" -czf - "$BACKUP_DATETIME-backup" \
|
|
| openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt \
|
|
-pass env:BACKUP_PASSPHRASE -out "$BACKUP_TEMP.tgz.enc"
|
|
echo "Success!"
|
|
echo
|
|
echo "Restore with:"
|
|
echo " openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \\"
|
|
echo " -pass env:BACKUP_PASSPHRASE -in $BACKUP_DATETIME-backup.tgz.enc | tar -xzf -"
|
|
echo
|
|
else
|
|
echo -n "Creating final tarball $BACKUP_DATETIME-backup.tgz ... "
|
|
tar -C "$BACKUP_DIR" -czf "$BACKUP_TEMP.tgz" "$BACKUP_DATETIME-backup"
|
|
echo "Success!"
|
|
echo
|
|
echo "WARNING: this archive is NOT encrypted. It carries password hashes,"
|
|
echo " active sessions, TOTP secrets and SMTP credentials in the"
|
|
echo " clear. Set BACKUP_PASSPHRASE to encrypt it, and store it"
|
|
echo " where you would store a copy of the database itself."
|
|
echo
|
|
fi
|
|
|
|
echo -n "Cleaning up temporary files and directories ... "
|
|
rm -rf "$BACKUP_TEMP"
|
|
echo "Success!"
|
|
echo
|
|
|
|
echo "Backup Complete!"
|