Tina: Broken Access Control: arbitrary bucket-key write/delete in `next-tinacms-s3` (and sibling production media adapters)

Beschreibung

## Zusammenfassung Der Produktionsmedien-Handler, der von `next-tinacms-s3` (`createMediaHandler` in `packages/next-tinacms-s3/src/handlers.ts`) ausgeliefert wird, akzeptiert einen vom Angreifer ausgewählten `?key=`-Abfrageparameter und gibt eine AWS-signierte `PutObject`-URL zurück, deren `Key` dieser Wert ist, ohne dass überprüft wird, ob der Schlüssel unter den vom Betreiber konfigurierten `mediaRoot` fällt. Der "DELETE"-Zweig des gleichen Handlers lautet "objectKey = (req.query.media als string[])[1]" und sendet einen "DeleteObjectCommand" für genau diesen Schlüssel, der wiederum von "mediaRoot" nicht begrenzt ist. Jeder Anrufer, der das vom Betreiber bereitgestellte `authorized()`-Prädikat besteht - d. H. Jeder angemeldete CMS-Editor in einer typischen TinaCloud / Self-Hosted-Bereitstellung - hat daher Schreib- und Löschberechtigung über das *gesamte * S3 Bucket kann der IAM-Schlüssel erreichen, obwohl das Paket "mediaRoot" als den Ort dokumentiert, an dem Editoren erfasst werden. Die gleiche Form ist in `next-tinacms-dos`, `next-tinacms-azure` und `next-tinacms-cloudinary` vorhanden, so dass ein einziger Designfehler jedes First-Party-Produktionsmedien-Backend umfasst. * Projekt: TinaCMS — First-Party-Produktionsmedienadapter (verbraucht von selbst gehosteten Next.js-Sites und TinaCloud-gestützten Bereitstellungen). * Quelle überprüft: `tinacms/tinacms` @ `main` (`b56dad4`). * Bereitgestelltes Artefakt validiert: `next-tinacms-s3@21.0.3` Handlerlogik, ausgeübt gegen `@aws-sdk/client-s3@3.665.x` via `aws-sdk-client-mock@4.1.0` (das AWS SDK signiert die URL identisch, unabhängig davon, ob der Bucket real oder verspottet ist). * Betroffene Datei(en): * `packages/next-tinacms-s3/src/handlers.ts:67-90` — `GET ?key=` gibt vorsignierte `PutObjectCommand`-URL mit attacker-chosen `Key` zurück. * `packages/next-tinacms-s3/src/handlers.ts:199-223` — `DELETE` liest `[, objectKey] = media` und gibt `DeleteObjectCommand` gegen attacker-chosen `Key` aus. * `packages/next-tinacms-dos/src/handlers.ts:79-152` und `:249-278` — dasselbe Schreib-/Löschmuster, plus einen serverseitigen Upload, der den Schlüssel mit `path.join(mediaRoot, prefix + filename)` über angreifergesteuertes `Directory` und `filename` aufbaut. `packages/next-tinacms-azure/src/handlers.ts:44-95` — `uploadMedia` schreibt `path.join(Verzeichnis, Dateiname)` mit beiden angreifergesteuerten Feldern (kein `mediaRoot` konfiguriert); `deleteAsset` löscht jeden Blob im Container. "packages/next-tinacms-cloudinary/src/handlers.ts:193-204" — "cloudinary.uploader.destroy(public id)" über attacker-chosen "public id". CWE: CWE-639 - Autorisierungsumgehung durch benutzergesteuerten Schlüssel. Nebenbei: CWE-284 (Improper Access Control), CWE-862 (Missing Authorization on the per-key authority check). * OWASP 2021: **A01:2021 — Broken Access Control** (die vom Betreiber beabsichtigte "mediaRoot" -Grenze wird nur beim Auflisten durchgesetzt, nicht beim Schreiben oder Löschen). Sekundär: A04:2021 - Unsicheres Design (jeder Adapter implementiert unabhängig voneinander das gleiche defekte Muster). ## Anfälliger Code `packages/next-tinacms-s3/src/handlers.ts:39-98`: ``ts export const createMediaHandler = (config: S3Config, options?: S3Options) => { const client = new S3Client(config.config) ..

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 23.0.4, 14.0.4, 26.0.4.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Microsoft next-tinacms-s3, next-tinacms-dos, next-tinacms-azure, next-tinacms-cloudinary.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.