Replace SSRF blocklist with allowlist or network policy approach #25
Description
Context
The callback URL validation in pkg/api/handler_tasks.go:98-105 uses a hostname blocklist to prevent SSRF:
blockedHosts := map[string]bool{
"169.254.169.254": true,
"localhost": true,
"127.0.0.1": true,
"::1": true,
"[::1]": true,
"0.0.0.0": true,
}Problem
A blocklist approach can never be complete. Known gaps include:
- Cloud metadata endpoints beyond AWS (Alibaba
100.100.100.200, AWS IPv6fd00:ec2::254, GCPmetadata.google.internal) 169.254.0.0/16range beyond just the metadata IP- IP encoding bypasses (decimal
2130706433= 127.0.0.1, octal, hex) - DNS rebinding attacks
- Private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Context on risk
Callback URLs are provided by adapters (trusted internal services), not arbitrary external users. The current blocklist is adequate defense-in-depth for this threat model, but a more robust approach would be better long-term.
Proposed alternatives (pick one or combine)
- Allowlist: Only allow callbacks to pre-registered or configured domains/CIDRs
- DNS resolution validation: Resolve the URL, validate ALL resolved IPs against blocked CIDR ranges (handles encoding bypasses and DNS rebinding)
- Network policies: Restrict egress from API pods at the K8s level
- Signed callback registration: Adapters register callback URLs via a separate authenticated endpoint; API only calls pre-registered URLs
Current mitigation
The existing blocklist covers the most common cases and is sufficient for now given that adapters are internal services.
Found during code review of the agent-sandbox migration branch.