@Aztech-Lab/dsh-3301

The HMAC key that signs dsh_session cookies is taken verbatim from a fixed path in the shared temp directory (~/tmp/dsh-3301-secret on POSIX). writeFileSync's mode only applies at creation, and the read path never verifies owner or type, so an unprivileged local user (or any process that can pre-create that filename before the service starts) determines the signing key. That attacker can then forge a valid dsh_session cookie over the LAN and bypass the gate entirely without knowing the password.

The default configuration binds all interfaces and serves HTTP; TLS is silently enabled only when both cert/key files already exist. On a LAN, Basic credentials and the 30-day dsh_session cookie (no Secure flag when TLS is off) cross the wire in clear text, so any on-path LAN attacker can capture and replay them, then use the proxy — and the proxy mints host-equivalent DSH sessions upstream.

Every text/html response the proxy returns is patched so the client-side transport reports ownsHost:true. DSH's own fence is meant to grant host-backed persistent settings and host-native actions (e.g. opening a produced file) only to loopback pages; this injection grants that level of trust to any authenticated LAN browser, so a single gate password compromise (or a stolen session cookie) also carries host-plane capability rather than read-only GUI access.

Credential verification uses plain string comparison, giving a (noisy, network-dependent) timing side channel on the gate password. Practical impact is limited — the per-IP lockout after 5 failures blunts repeated probing — but the cookie path already uses crypto.timingSafeEqual, so this is an inconsistency rather than a necessity.