Security: plugin SSRF guard runs once — redirects bypass it

[mimeding]

Summary

Why this matters (business)

The plugin Host API gives plugins a sandboxed way to make HTTP requests. The whole point of the SSRF guard there is to keep a compromised or malicious plugin from using that capability to reach things it shouldn't — the local Osaurus server (http://127.0.0.1:<port>), the cloud metadata service (http://169.254.169.254/), RFC1918 internal targets on the user's network, etc.

That guard ran exactly once, on the URL the plugin originally requested. URLSession then quietly followed any redirects without re-checking. So:

1. A malicious endpoint responds 302 Location: http://127.0.0.1:1337/v1/chat/completions.
2. URLSession follows the redirect with full credentials.
3. The plugin gets a response from the local Osaurus server.
4. SSRF was never asked about the redirect target.

follow_redirects defaults to true, so plugins don't even need to opt in to be exposed. This is the canonical SSRF bypass and it's worth closing before the plugin ecosystem grows.

What's wrong (technical)

        if let ssrfError = Self.checkSSRF(url: url) {
            return Self.jsonString(["error": "ssrf_blocked", "message": ssrfError])
        }
        ...
        let followRedirects = json["follow_redirects"] as? Bool ?? true
        ...
        let session = followRedirects ? Self.httpSession : Self.noRedirectSession

httpSession was created without any delegate, so URLSession's default redirect handling kicked in — no re-validation of the new URL:

    private static let httpSession: URLSession = {
        let config = URLSessionConfiguration.ephemeral
        config.httpMaximumConnectionsPerHost = 10
        return URLSession(configuration: config)
    }()

noRedirectSession already had a NoRedirectDelegate that suppresses all redirects, but that only applies when the plugin explicitly passes follow_redirects: false.

Fix

Attach a new SSRFCheckedRedirectDelegate to httpSession. On every redirect, the delegate runs the same PluginHostContext.checkSSRF it ran on the initial URL. If the new target is RFC1918, loopback, link-local, or otherwise blocked, the delegate refuses by passing nil to URLSession's completion handler. URLSession then surfaces the original 3xx response (status + headers) to the plugin — so plugins can detect the blocked redirect from the response status code without anyone connecting to the private target.

The no-redirect session is unchanged. Behavior for plugins that never hit a redirect, or that explicitly disable redirects, is byte-for-byte identical.

Scope decisions

• This closes the redirect-bypass path. It does not yet close DNS rebinding — checkSSRF is still string-based on the hostname. A public-looking.example.com that resolves to 127.0.0.1 is still let through. Fixing that requires resolving the hostname inside the SSRF guard and validating the resolved IPs (potentially per-redirect-hop), which is a much bigger change and worth doing in its own focused PR.
• The default for follow_redirects is intentionally left at true to preserve API compatibility. With the redirect re-check in place, that default no longer creates the bypass.

Changes

• Behavior change (security fix: SSRF guard now applied per redirect hop)
• UI change
• Refactor / chore
• Tests (the existing SSRFProtectionTests cover the underlying checkSSRF; the redirect-delegate hook is a thin URLSession-callback glue layer that's hard to unit-test without a real or mocked URL stack)
• Docs

Test Plan

1. Start the server. From a test plugin, http_request to an attacker-controlled URL that 302-redirects to http://127.0.0.1:1337/agents. Expected: the plugin sees the 302 response (not the local API contents). Previously: the plugin saw the local API contents.
2. Sanity: same plugin requests a public URL that 302-redirects to another public URL — the redirect should be followed as before.
3. Sanity: follow_redirects: false — first response (even if 30x) is returned verbatim, unchanged.
4. Existing SSRFProtectionTests continue to pass (they test the underlying checkSSRF function which is unchanged).

Checklist

• I have read CONTRIBUTING.md
• I added/updated tests where reasonable (see scope decisions — the underlying guard is covered)
• I updated docs/README as needed (n/a — plugin API surface unchanged)
• I verified build on macOS with Xcode 16.4+ (authored in a Linux sandbox; verified the touched file via swiftc -frontend -parse)