[jherforth]

Fixes four plugin-reachable problems from Mrramam's audit: mrramam#54, #60 and two parts of #56. These are the ones that don't depend on the plugin-isolation work (#50, #49), which is coming as its own change.

Fixes

• Storage increment reached Object.prototype (feat: multi-tenancy #54). The increment walked the caller's dot-path with no filtering. A __proto__.x path, from POST …/increment or a manifest reaction, therefore wrote onto Object.prototype for the whole server process.
  • Paths containing __proto__, constructor or prototype are now refused with 400. The route, manifest validation and the increment function itself all check this.
  • The increment now steps through own properties only.
• Increment skipped the 500-key cap (feat: Day/Night mode #60). PUT counted keys, increment didn't. A new key now counts against the cap inside the same transaction, and over the cap it answers 413.
• Proxy redirects (1.3 release #56). /api/proxy checked only the first address, then followed up to five redirects anywhere. A whitelisted host could therefore send it to an address on the household's network.
  • Every hop is now checked against the whitelist in beforeRedirect. A redirect off the list answers 403, and the off-list host is never contacted.
  • Only http(s) addresses are fetched.
• GitHub install (1.3 release #56). It fetched any download_url and echoed the upstream body on errors.
  • It now accepts only files in jherforth/HomeGlowPlugins on raw.githubusercontent.com. These are the only addresses the listing gives.
  • It follows no redirects and no longer echoes the response body.

Not in this PR

Plugin isolation, and the open CORS behind it: #50, #49 and the CORS part of #62. While plugins run same-origin and the API allows any origin, a plugin can still call every route directly. That fix changes how all plugins run, so it comes separately.

Testing

• Server npm test: 609 pass. New tests cover each of these cases:
  • __proto__ and constructor.prototype paths are refused, and nothing is stored;
  • a reaction with an unsafe path is refused at upload;
  • an increment past the cap answers 413, while an existing key still works;
  • a redirect off the whitelist is refused, and a second server records that it was never reached;
  • a redirect between whitelisted addresses still works;
  • an ftp: address is refused;
  • four bad GitHub install addresses are refused.
• Against the old server code, the five tests for these bugs fail, so they catch them. The allowed-redirect test passes either way, as it should.

🤖 Generated with Claude Code

[mrramam]

One gap in the GitHub install check: startsWith runs on the raw string, but the URL is normalized when it's fetched. So https://raw.githubusercontent.com/jherforth/HomeGlowPlugins/%2e%2e/%2e%2e/<anyone>/<repo>/main/x.html passes the check and resolves to another repo's file. It stays on raw.githubusercontent.com, so this isn't a route into the household's network. Since /api/widgets/upload is open anyway, it's a small gap, but the check promises "only files in jherforth/HomeGlowPlugins". Parsing first closes it: const u = new URL(download_url), then check u.origin and u.pathname.startsWith('/jherforth/HomeGlowPlugins/').

[jherforth]

The GitHub install check could be bypassed with an encoded .. in the address, loading another repo's file. It stayed on GitHub, so it was no route into the home network.
Fixed: the address is now parsed first, and must be a file inside jherforth/HomeGlowPlugins once normalized.
Checked: his address and several variants are refused. Real store addresses, including #53's nested folders and a name with spaces, still install. CI passes on the new commit.