gabriel / musehub public
Closed #162 Bug production-readiness
filed by gabriel human · 68 days ago

Production readiness — Section 14: Application Security

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Full detail

Confirmed strong existing posture: no SQL injection surface (parameterized queries throughout), path traversal and zip-bomb protection already implemented, MSign requires fresh signatures for privileged actions, CORS fails closed, thorough upload/quota limits.

Fixed this session: the /_debug/memory endpoint was exposed unconditionally in production (missing the same settings.debug guard /docs and /redoc correctly have) — patched.

Remaining: CSRF review, WebSocket/SSE auth review, SSRF review of musehub/worker.py specifically, data classification/retention docs, formal OWASP-oriented pass before launch.

◎ Activity1
●
gabriel opened this issue 68 days ago
○
gabriel 38 days ago

Reviewed every remaining gap with real code inspection, not just assumptions.

Resolved:

  • SSRF protection confirmed real and actually wired in — musehub/security/ssrf.py (two-layer: sync field validation + async DNS-rebinding check), enforced in both musehub/models/musehub.py and the webhook dispatcher. (The original doc guessed this lived in worker.py — it doesn't; that's the unrelated background job processor.)
  • CSRF confirmed genuinely N/A — zero cookie-setting code anywhere in the codebase.
  • MCP/SSE authentication confirmed correct — same MSign mechanism throughout (TokenClaims/optional_token are just re-exported aliases for the real implementation), optional at connection level, enforced per-privileged-action.
  • Account/data deletion mechanism confirmed to exist (soft-delete via deleted_at).

Real finding: MSign's per-request signing (request_signing.py) only enforces a 30-second freshness window — it does not track or reject a duplicate (handle, ts, sig) replayed within that window. No nonce/dedup exists for it, unlike the codebase's own auth-challenge and MPay flows which do have single-use nonces. Corrected the docstring's overstated "replay protection" claim to describe what it actually does. Practical severity is real but narrow (needs an attacker to capture a signed request within 30s, and a non-idempotent action to matter).

Split remaining work (build the actual dedup fix, content scanning, retention policy, formal OWASP pass) to #178.

Closing.

✓
closed this issue 38 days ago