The console's login throttle was documented as per-IP and was not. Nitro's `localFetch` hands the app a synthetic request whose socket has no `remoteAddress`, so `getRequestIP()` returned undefined for every request and every attempt was charged to one shared "unknown" bucket. Five wrong guesses from any LAN peer locked out everyone — including the operator, and including the update-apply route, which shares that budget. The Bun entry is the only place the real peer is knowable, so it now stamps it into a header (deleting any client-supplied copy first) and `peerAddress()` reads it back. Verified on a real build bound to 0.0.0.0: seven wrong logins from 127.0.0.1 lock 127.0.0.1 out, a different peer still logs in on the first try, and a request forging the header is charged to its real address. Also on the way through: - Installing an unreviewed package and adding a catalog source now re-ask for the console password, like applying an update already did. A 7-day session cookie should not be able to run new code on the host, and `store/install` with `accept_unverified` did exactly that through the generic passthrough. The gate sits at the trust boundary — adding a source, or a raw spec — not on every install from a source the operator already chose to trust. - The ui-credential denylist is matched against the normalised path too, so `/api//v1/...` and friends can no longer walk around it. - The console serves nosniff, a no-referrer policy, and a CSP that pins frame-ancestors, object-src and base-uri. - A plugin UI's response no longer re-emits the content-encoding that `fetch` already decoded (which made compressed plugin pages fail to load), no longer sets cookies on the console's origin, and OPTIONS reaches the plugin instead of being refused 405 by us. - An unreachable host reads as 502 on these routes, matching the passthrough, instead of a bare 500. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
22 lines
1.2 KiB
TypeScript
22 lines
1.2 KiB
TypeScript
// POST /api/v1/update/apply — a proxied route with an extra gate: the console password must be
|
|
// re-entered per apply (design host-update-from-web-console.md §4.3). A 7-day session cookie alone
|
|
// must not be able to update-and-restart the host; the password is verified in `confirmPassword`
|
|
// (only the BFF knows it), stripped, and never forwarded. Wrong attempts share the login throttle's
|
|
// per-peer budget, so apply can't be used as a password oracle.
|
|
//
|
|
// This specific file wins over the `[...]` catch-all (h3 route specificity) — verified in the
|
|
// U1 gate; everything else about proxying (bearer injection, loopback TLS scoping, 401→502)
|
|
// lives in util/forward.ts and mirrors ../../[...].ts.
|
|
import { defineEventHandler, readBody } from "h3";
|
|
import { confirmPassword } from "../../../../util/confirm";
|
|
import { forwardJson } from "../../../../util/forward";
|
|
|
|
export default defineEventHandler(async (event) => {
|
|
const body = await readBody<{ password?: string; force?: boolean }>(event);
|
|
confirmPassword(event, body?.password);
|
|
// The password stops here — the host only ever sees the force flag.
|
|
return forwardJson(event, "/api/v1/update/apply", "POST", {
|
|
force: body?.force === true,
|
|
});
|
|
});
|