Skip to content

feat(security): SSRF guard for outbound webhooks + partner postbacks - #64

Open
keithfawcett wants to merge 2 commits into
mainfrom
fix/outbound-ssrf-guard
Open

feat(security): SSRF guard for outbound webhooks + partner postbacks#64
keithfawcett wants to merge 2 commits into
mainfrom
fix/outbound-ssrf-guard

Conversation

@keithfawcett

Copy link
Copy Markdown
Contributor

What & why

Both server-side fetch sinks accepted attacker-influenced URLs with only syntactic (z.string().url()) validation, then fetched them with no host/IP restriction and default redirect-following:

  • webhook-dispatcher.ts → tenant-admin-configured webhook URLs (/webhooks/:id/test fires on demand)
  • partner-postback.tspartner-configured postback URLs (lower privilege), fetched after macro substitution

Neither is fully blind — the webhook test route returns status/error and postbacks store lastStatus/lastError — so both were usable as internal port-scan / cloud-metadata oracles (169.254.169.254, RFC1918, loopback, …). Found via an unsteered Codex review; mitigation design pressure-tested with Codex.

The guard (outbound-guard.ts, block-by-default)

  1. http/https only, no embedded credentials, port on the policy allowlist.
  2. Resolve every address; reject unless each is globally-routable public unicast (ipaddr.js). Rejects IPv4-mapped IPv6 and octal/hex/decimal IPv4 encodings (WHATWG URL normalizes them before we classify). Special-use hostnames (localhost, .local, .internal, .home.arpa, single-label) refused without a DNS trip.
  3. DNS-pin the validated address into a per-request undici dispatcher's connect.lookup so DNS can't rebind between check and connect; the original URL still supplies Host/SNI/cert identity (only socket resolution is substituted).
  4. redirect: 'manual', zero hops — a 3xx is a non-delivery (following would re-open the hole).

Blocked destinations throw OutboundBlockedError with a stable code (safe for the partner-visible lastError), recorded as a failed delivery via the existing catch paths.

Policy is deployment-scoped

  • Hosted (any mode but selfhost+single): ports locked to 80/443; no private CIDRs.
  • Self-host single-tenant: ports unrestricted; honors OPENPARTNER_OUTBOUND_ALLOW_PRIVATE_CIDRS (comma-separated CIDRs) for localhost testing. This env fails startup if set in any other mode.
  • OPENPARTNER_OUTBOUND_ALLOWED_PORTS lets an operator widen ports (e.g. 80,443,8443). Not tenant-configurable.

Blast-radius check (done before choosing block-by-default)

Queried prod read-only: all 9 configured webhook endpoints are public HTTPS on 443 (Zapier ×7, xispark.com, a Supabase edge function) and 0 partner postbacks exist. So block-by-default breaks nothing currently live.

Tests

outbound-guard.test.ts: schemes, ports, credentials, every private/loopback/link-local/CGNAT/unspecified class, IPv4-mapped IPv6, octal/hex/decimal loopback encodings, special-use hostnames, the port allowlist, the private-CIDR escape hatch, the env fail-closed check, and a live-server test proving a blocked host never receives a socket (+ that the escape hatch reaches it). The existing webhook + postback integration suites set the selfhost escape hatch for their localhost receivers. Full API suite green; typecheck + lint (0 errors) clean.

Notes / follow-ups

  • Deps added: undici, ipaddr.js.
  • Codex flagged Node 20 is EOL (Mar 2026) — the runtime-floor bump to Node 22 is a separate PR (this uses undici@6, which runs on both 20 and 22, so the two PRs are independent).
  • Residual (infra-layer, not code): egress firewall rules + per-tenant outbound rate limits are still worth adding; a permitted public endpoint can still act as a relay.

🤖 Generated with Claude Code

Both server-side fetch sinks took attacker-influenced URLs with only
syntactic (z.string().url()) validation: webhook endpoint URLs (tenant
admin) and partner postback URLs (partner — lower privilege), then fetched
them with no host/IP restriction and default redirect-following. Neither is
fully blind — the webhook test route returns status/error and postbacks
store lastStatus/lastError — so both were usable as internal port-scan /
metadata oracles (169.254.169.254, RFC1918, loopback, …).

Adds a shared block-by-default guard (outbound-guard.ts) applied at both
sinks:
- http/https only, no embedded credentials, port on the policy allowlist.
- Resolve EVERY address; reject unless each is globally-routable public
  unicast (ipaddr.js). Rejects IPv4-mapped IPv6, and octal/hex/decimal IPv4
  encodings (WHATWG URL normalizes them before classification). Special-use
  hostnames (localhost/.local/.internal/.home.arpa/single-label) refused.
- DNS-pin the validated address into a per-request undici dispatcher's
  connect.lookup so DNS can't rebind between check and connect; the original
  URL still supplies Host/SNI/cert identity.
- redirect: 'manual', zero hops — a 3xx is a non-delivery.
Blocked destinations throw OutboundBlockedError with a stable code (safe to
store in partner-visible lastError), recorded as a failed delivery.

Policy is deployment-scoped: hosted locks ports to 80/443; selfhost+single
leaves ports open and honors OPENPARTNER_OUTBOUND_ALLOW_PRIVATE_CIDRS (an
escape hatch that FAILS STARTUP if set in any other mode). Checked prod
first: all 9 configured webhooks are public HTTPS/443 and there are 0
postbacks, so block-by-default breaks nothing live.

Design reviewed adversarially with Codex. Deps: undici + ipaddr.js. Tests:
outbound-guard.test.ts (schemes/ports/creds/IP classes/encodings/hostnames/
escape hatch + a live-server check that a blocked host never gets a socket);
existing webhook + postback integration tests set the selfhost escape hatch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ail-fast boot

Two findings from Codex review of the SSRF guard:

1. (HIGH-when-enabled) The private-CIDR escape hatch was shared with
   partner-controlled postbacks, so an operator opening an internal range
   for an admin webhook also handed every partner a scan/request oracle
   across it. safeFetch now takes a trust level: partner postbacks use a
   hardened policy (escape hatch stripped, ports never unrestricted — 80/443
   fallback); admin webhooks keep the full deployment policy. Callers pass
   trust: 'admin' (webhook-dispatcher) / 'partner' (partner-postback).

2. (LOW) "Refuses to boot on bad config" was documented but not enforced —
   the policy built lazily on first delivery. server.ts now calls
   outboundPolicy() before listen(), so a misconfigured OPENPARTNER_OUTBOUND_*
   fails startup.

Tests: new guard case asserting admin honors the escape hatch while partner
does not (and never opens a socket); the postback integration test uses the
new __setOutboundPolicyForTests override for its localhost receiver (the
security split itself is covered in outbound-guard.test.ts).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant