Findings from the audit (50-check harness across guest/user/uploader/staff/ admin) and their fixes: - SSRF: 'Download to Library' and the staged-upload resolve path fetched any http(s) URL. services.validate_remote_url now enforces the e621 media allowlist and open_remote re-validates every redirect hop; the download-task create endpoint and the guest proxy use them, so internal addresses (127.0.0.1, LAN, metadata) are rejected with 400. - Privilege escalation: staff could promote users to staff and demote other staff. Role changes across the staff boundary now require an admin, matching the account-deletion rules; the Users page hides what the backend would refuse. - SPA-only gating: /api/storage/ and /api/duplicates/* were readable by any authenticated account (absolute paths, duplicate groups) while the SPA only shows them to uploaders. They now require CanUpload. - Throttling (REST_FRAMEWORK, env-overridable, counted in Redis): anon 120/min, user 600/min, login 5/min, register 20/hour, guest e621 proxy 60/hour. Login now goes through a throttled view. - e621 API keys are encrypted at rest with a Fernet key derived from SECRET_KEY (apps/accounts/crypto.py); a data migration encrypts existing rows and the column widens first. Reads decrypt transparently, legacy plaintext still works, and a changed SECRET_KEY reads as 'not configured' instead of leaking. Rotating SECRET_KEY now invalidates stored keys as well as signed media URLs. - Hardening: the server refuses to start with DEBUG=False while SECRET_KEY is still the development default. Verified: corrected harness 50/50 (guest visibility, IDOR, signed-URL tamper/expiry, staged-upload/similarity privacy, role matrix, SSRF), login throttles at the 6th attempt with 429, anon polling unaffected, the guest proxy still reaches allowlisted hosts, live e621 auth works with the decrypted key, and DB rows hold only ciphertext.
49 lines
1.4 KiB
Python
49 lines
1.4 KiB
Python
"""Symmetric encryption for secrets stored at rest, keyed by SECRET_KEY.
|
|
|
|
Used for the per-user e621 API keys: a database dump (or backup) alone does
|
|
not expose them. Rotating SECRET_KEY makes existing values undecryptable,
|
|
exactly like the signed media URLs stop verifying — users then re-enter
|
|
their e621 key.
|
|
"""
|
|
|
|
import base64
|
|
import hashlib
|
|
|
|
from cryptography.fernet import Fernet, InvalidToken
|
|
from django.conf import settings
|
|
|
|
PREFIX = "enc:"
|
|
|
|
|
|
def _fernet() -> Fernet:
|
|
# Derive a stable Fernet key from the project secret.
|
|
digest = hashlib.sha256(
|
|
f"j621-secret-v1:{settings.SECRET_KEY}".encode()
|
|
).digest()
|
|
return Fernet(base64.urlsafe_b64encode(digest))
|
|
|
|
|
|
def encrypt_secret(value: str) -> str:
|
|
"""Encrypt for storage; empty stays empty and already-encrypted passes through."""
|
|
if not value:
|
|
return ""
|
|
if value.startswith(PREFIX):
|
|
return value
|
|
return PREFIX + _fernet().encrypt(value.encode()).decode()
|
|
|
|
|
|
def decrypt_secret(value: str) -> str:
|
|
"""Decrypt a stored value; legacy plaintext passes through.
|
|
|
|
Returns "" when the value cannot be decrypted (e.g. SECRET_KEY changed),
|
|
which reads as "not configured" and asks the user for the key again.
|
|
"""
|
|
if not value:
|
|
return ""
|
|
if not value.startswith(PREFIX):
|
|
return value
|
|
try:
|
|
return _fernet().decrypt(value[len(PREFIX) :].encode()).decode()
|
|
except InvalidToken:
|
|
return ""
|