Vom Angreifer kontrollierte OAuth-redirect_uri → Übernahme eines Admin-Kontos per Klick

Zusammenfassung

Der OAuth-Login von txAdmin baut die Callback-URL aus einem Wert zusammen, den der Aufrufer frei per Query-Parameter mitgibt — ohne jede Prüfung gegen einen Host oder eine Allowlist. Gleichzeitig wird der OAuth-state an die Sitzung des Aufrufers gebunden, nicht an die Person, die sich später tatsächlich anmeldet. Es gibt kein PKCE.

In der Summe kann ein nicht authentifizierter Angreifer eine Login-URL erzeugen, deren Callback auf sein eigenes Ziel zeigt, diese an einen Panel-Admin schicken, und nach dessen normalem Login die entstandene Sitzung als dieser Admin übernehmen.

Ursache

1. Der Redirect-Endpunkt liest die Herkunft (origin) aus der Query und baut daraus die OAuth-redirect_uri — der Wert wird als beliebiger String akzeptiert, ohne Host-/Allowlist-Prüfung.
2. Der OAuth-state ist an die Sitzung des Anfragenden gebunden, nicht an die anmeldende Person.
3. Der Token-Tausch verwendet die in der Sitzung gespeicherte (angreiferseitige) Callback-URL, und es gibt kein PKCE — obwohl die Metadaten des Identity-Providers PKCE (S256) ausdrücklich anbieten. Nichts bindet den Autorisierungs-Code an das legitime Panel.
4. Beim Callback authentifiziert txAdmin jede Sitzung, die ein gültiges Code+State-Paar vorlegt, als das Konto, das sich angemeldet hat.

Weil OAuth die stärkere Anmeldemethode ist, umgeht der Angriff die Passwort-Härtung vollständig.

Auswirkung

Vollständige Übernahme eines beliebigen txAdmin-Admin-Kontos (inklusive Master) durch einen entfernten, nicht authentifizierten Angreifer plus einen einzigen geklickten Link. Master-Zugriff bedeutet beliebige Änderungen an server.cfg und Resources — und damit Codeausführung auf dem Host des Spielservers.

Behebung

1. Die vom Client gelieferte Herkunft niemals vertrauen: die Callback-Herkunft serverseitig aus dem Request-Host (proxy-bewusst) oder aus einer konfigurierten Basis-URL/Allowlist ableiten und Abweichungen ablehnen.
2. PKCE (S256) aktivieren — der Identity-Provider unterstützt es laut seinen eigenen Metadaten. PKCE allein würde den Einlöse-Schritt selbst bei offener redirect_uri unterbinden.
3. Beim Callback prüfen, dass die vorgelegte Callback-Herkunft mit der in der Sitzung gespeicherten übereinstimmt (Defense in Depth).