OIDC-Token-Diebstahl durch extern kontrollierte URL

Zwei Datenquellen, die in der mit der offiziellen OHIF-Distribution ausgelieferten Konfiguration registriert sind, lesen eine URL aus dem ?url=-Query-Parameter und rufen sie ab: ohne Origin-Prüfung, ohne Einschränkung des URL-Schemas, ohne Allowlist. Beide liegen auf automatisch erzeugten Routen (/:modeRouteName/dicomwebproxy und /:modeRouteName/dicomjson), sodass ein präparierter Link sie ohne jede deployment-spezifische Konfiguration erreicht.

initialize: async ({ params, query }) => {
  const url = query.get('url');

  if (!url) {
    throw new Error(`No url for '${name}'`);
  } else {
    const response = await fetch(url);
    const data = await response.json();
    if (!data.servers?.dicomWeb?.[0]) {
      throw new Error('Invalid configuration returned by url');
    }

    dicomWebDelegate = createDicomWebApi(
      data.servers.dicomWeb[0].configuration || data.servers.dicomWeb[0],
      servicesManager
    );
    dicomWebDelegate.initialize({ params, query });
  }
},

Das abgerufene Dokument wird als DICOMweb-Serverkonfiguration geparst, und seine Werte für wadoRoot und qidoRoot werden zu den Endpunkten für jede folgende Metadaten- und Bildanfrage. Die zweite Datenquelle nimmt denselben Parameter entgegen und parst die Antwort als Studien-Manifest, in dem jede instance.url zum Ziel eines Bildabrufs wird.

initialize: async ({ query, url }) => {
  if (!url) {
    url = query.get('url');
  }
  let metaData = getMetaDataByURL(url);

  // ...

  const response = await fetch(url);
  const data = await response.json();

Der Abruf allein ist noch nicht die Offenlegung. Das Credential folgt, weil userAuthenticationService ein globales Singleton ist und nichts seinen Token an eine Origin oder an die anfragende Datenquelle bindet. Sobald der Klinik-Nutzer angemeldet ist, hängen zwei voneinander unabhängige Pfade diesen Token an genau den Endpunkt, den die aktive Datenquelle benennt.

getAuthorizationHeader = () => {
  const xhrRequestHeaders: HeadersInterface = {};
  const authHeaders = userAuthenticationService.getAuthorizationHeader();
  if (authHeaders && authHeaders.Authorization) {
    xhrRequestHeaders.Authorization = authHeaders.Authorization;
  }
  return xhrRequestHeaders;
};

Diese Closure wird vor jeder Abfrage neu ausgewertet statt einmalig gespeichert (qidoDicomWebClient.headers = getAuthorizationHeader()), der Header trägt also einen gültigen und keinen veralteten Token. Parallel dazu hängt der Cornerstone-Image-Loader denselben Header über einen globalen beforeSend-Hook an jede Pixeldaten-Anfrage.

beforeSend: function (xhr) {
  const sourceConfig = extensionManager.getActiveDataSource()?.[0].getConfig() ?? {};
  const headers = userAuthenticationService.getAuthorizationHeader();

  const xhrRequestHeaders = {
    Accept: acceptHeader,
  };

  if (headers) {
    Object.assign(xhrRequestHeaders, headers);
  }

  return xhrRequestHeaders;
},

Wir haben beide Routen am 19.02.2026 gegen das offizielle Image ohif/app:v3.12.0 mit Keycloak 24.0.5 als OIDC-Provider vollständig bestätigt. Der Link trug selbst keinen Token; der Angreifer-Server erhielt den gültigen Keycloak-Access-Token des angemeldeten Klinik-Nutzers, einmal über den DICOMweb-Abfragepfad und einmal über den Image-Loader-Pfad.

[*] GET /config.json - serving DICOMweb configuration
[!] GET /steal/studies?limit=101&offset=0&StudyInstanceUID=1.2.3
    Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
[!] GET /steal/studies/1.2.3/series?includefield=00080021,00080031
    Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

[*] GET /studies.json - serving study manifest
[!] GET /steal/image.dcm
    Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Der dekodierte Token war der gültige Access-Token des Test-Kontos, ausgestellt vom Keycloak-Realm für den Client ohif-viewer, mit einer Session-Kennung passend zur aktiven Browser-Sitzung. Es handelt sich um ein Credential, nicht um eine Kopie der Studiendaten: gegen das Imaging-Backend wiedereingespielt gewährt es genau die Zugriffe, die dem Nutzer zustehen.

OHIF hat am 21.04.2026 #5963 und am 27.04.2026 #5973 gemergt und damit einen secureConfigFetch-Helper eingeführt. In einem authentifizierten Deployment muss eine Cross-Origin-Konfigurations-URL nun in einer vom Betreiber konfigurierten Allowlist stehen, bevor sie überhaupt abgerufen wird.

if (isAuthenticated && !isSameOrigin) {
  const normalizedAllowedOrigins = normalizeAllowedOrigins(allowedOrigins);
  if (!normalizedAllowedOrigins.length || !normalizedAllowedOrigins.includes(parsedUrl.origin)) {
    throw new Error(
      `Blocked remote configuration origin "${parsedUrl.origin}" in authenticated environment`
    );
  }
}

Maintainer Joe Boccanfuso bat uns, diesen Fix zu validieren. Am 28.04.2026 haben wir die Testumgebung der Erstmeldung gegen ohif/app:v3.13.0-beta.63 neu aufgebaut und bestätigt, dass der Cross-Origin-Angriff abgewiesen wird, bevor eine Anfrage überhaupt abgesetzt wird. Die Prüfung stützte sich allerdings auf die URL in ihrer geschriebenen Form, nicht auf die tatsächlich zurückgelieferte Antwort. Eine Same-Origin-URL übersprang die Allowlist vollständig und wurde anschließend mit dem Browser-Standard redirect: 'follow' abgerufen, sodass ein einzelner Open Redirect irgendwo auf der Origin des Deployments den ursprünglichen Angriff wiederherstellte. Wir haben einen solchen als nginx-Location return 302 $arg_to in die Testumgebung eingebaut und den Token des Klinik-Nutzers erneut auf zwei getrennten Abfragen abgegriffen. Redirect-Endpunkte dieser Art sind in der Schicht vor einem klinischen Viewer alltäglich: Gateways nach Art von oauth2-proxy, auth_request-Flows, SSO-Portale und OIDC-Callback-Handler.

Wir haben die Lücke am selben Tag gemeldet. Joe eröffnete am Folgetag #5985 gegen master und #5978 als Backport für 3.12 und fasste die Verzweigung in fetchConfigJson so zusammen, dass ein einziger Satz gehärteter Optionen für jeden Abruf gilt.

async function fetchConfigJson(normalizedPolicy) {
  const { normalizedUrl } = normalizedPolicy;
  const response = await fetch(normalizedUrl, {
    method: 'GET',
    mode: 'cors',
    credentials: 'same-origin',
    redirect: 'error',
    referrerPolicy: 'no-referrer',
  });

redirect: 'error' bricht den Abruf bei jedem 30x ab und schließt damit den Redirect-Pfad; credentials: 'same-origin' und referrerPolicy: 'no-referrer' begrenzen unabhängig davon, was ein Konfigurationsabruf nach außen mitführen kann. Wir haben am 29.04.2026 beide Pull-Request-Stände lokal gebaut und die Testumgebung gegen jeden laufen lassen: Cross-Origin und Same-Origin-Redirect wurden auf beiden Branches blockiert, ohne Regression. Der Backport-Commit 838f5195 ist ein Vorfahr des Tags v3.12.2, das veröffentlichte Release trägt also nicht nur die Allowlist, sondern auch die Redirect-Härtung.