guard.get_checked previously resolved a name for the address check and then let
the client resolve it again to connect, so a ~0-TTL record could flip to
127.0.0.1 (or the metadata endpoint) between the two — the exact gap the module
docstring called out as "not covered".
Every hop now connects to the address that passed its check: the request URL
carries the vetted IP, Host keeps the original name (and explicit port) for
virtual hosting, and the sni_hostname extension keeps the TLS handshake — and
certificate verification — against the name. Literal-IP URLs are unchanged.
Redirect Locations are resolved against the logical URL, and the final logical
URL rides resp.extensions["logical_url"] so web_fetch reports the name, not the
pinned address.
Verified against a local TLS server whose cert carries only DNS:pinned.test:
the pinned request (URL=127.0.0.1, sni_hostname=pinned.test) verifies and the
server sees Host: pinned.test; the same request without the extension fails
with "IP address mismatch" — httpcore does verify certificates against
sni_hostname, not the URL host.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Follow up to #290. Add RFC 6598 shared space (100.64.0.0/10, used by
Tailscale) to the address guard, and run the same guard on the Playwright
browser_open_url before navigating.
web_fetch and browser_read_url take a URL straight from the model. The model's
input is untrusted by design - both tools' own descriptions call fetched
content "data to evaluate, not instructions" - and web_fetch is
requires_approval=False, so nothing prompts the user before the request goes
out.
Neither validated the address. Verified against a scratch server on loopback:
web_fetch("http://127.0.0.1:9931/")
-> {"text": "Directory listing for /\n.git/\n.github/..."}
No prompt, no error. The same call reaches http://169.254.169.254/ for cloud
metadata when OpenWorker runs on a VM, an Ollama instance on :11434, or any
service on the user's LAN. It cannot reach OpenWorker's own sidecar, which
requires COWORKER_API_TOKEN.
Adds coworker/web/guard.py: resolve the host and refuse when any answer lands
in loopback, private, link-local (which covers the metadata endpoint),
multicast or reserved space. Checking every resolved address means a name with
one public and one private A record is refused rather than raced.
Redirects are the usual bypass, so follow_redirects is off and the chain is
walked here with each hop checked before it is requested. _request grows an
opt-in check_addresses flag used only by browser_read_url; the hardcoded vendor
endpoints the rest of the connectors call skip the guard and its DNS lookup.
Not covered, and stated in the module docstring: DNS rebinding. The name is
resolved by the guard and again by the client when it connects, so a near-zero
TTL record can change in between. Closing that needs connection-level IP
pinning. The hop check is the cheap 90%.
Tests: tests/test_url_address_guard.py - literals, IPv4-mapped IPv6 loopback,
names resolving into private space, split-horizon answers, non-http schemes,
redirect into loopback proven not to be requested, and a bounded redirect
loop.
