Security: harden screenshot tool against SSRF via redirect chains

[zpbrent]

Summary

src/tools/http_request.rs and src/tools/web.rs already validate redirect chains for SSRF protection.

src/tools/screenshot.rs still follows redirects without equivalent hop-by-hop validation, which can allow SSRF via intermediate redirects to internal/private addresses.

Problem

A URL that appears safe at first request can redirect to:

• localhost / loopback
• private RFC1918 ranges
• link-local or metadata endpoints
• non-http(s) schemes

Without per-hop checks, the screenshot tool may navigate to blocked destinations.

Scope

Apply the same redirect-chain SSRF hardening used by HTTP/web tools to screenshot capture:

• Validate every redirect target before following.
• Enforce redirect limit.
• Validate final destination URL.
• Keep DNS/private-network checks consistent with existing tooling.

Acceptance Criteria

• Screenshot preflight rejects redirect hops to blocked/private/local targets.
• Screenshot preflight rejects non-http(s) redirect targets.
• Redirect-loop or excessive hop chains fail with a clear error.
• Unit tests cover redirect-target validation and regression cases.

Notes

This is a parity/security consistency fix with existing SSRF protections in:

• src/tools/http_request.rs
• src/tools/web.rs

[zpbrent]

Implemented browser-native SSRF redirect protection for the screenshot tool (instead of copying reqwest redirect-policy logic).

What changed

• Added CDP Fetch interception (Fetch.requestPaused) in the screenshot flow.
• Created the page at about:blank, enabled interception, then navigated so checks run before/through navigation.
• For every paused browser request (including redirect hops), validated:
  • scheme is http/https
  • host is not local/private/blocked
  • DNS resolution does not resolve to private/local IPs
• Allowed safe requests via Fetch.continueRequest.
• Blocked unsafe requests via Fetch.failRequest(ErrorReason::AccessDenied).
• Kept initial entry URL SSRF validation as defense-in-depth.

Why this approach

This enforces SSRF checks on the actual browser request chain (including redirects), which is more accurate than an external preflight client and matches real navigation behavior in Chromium.

Validation performed

• cargo fmt -- --check
• cargo clippy --features screenshot -- -D warnings
• cargo test --features screenshot --lib screenshot::tests:: (24 passed)
• cargo test --features screenshot (no failures)

If needed, I can follow up with additional integration coverage for redirect-heavy scenarios once a controlled test harness server is available.