Wissen › Broken Access Control / IDOR
Broken Access Control / IDOR
Fehlende Berechtigungsprüfung: eine hochgezählte ID genügt, um fremde Daten zu sehen.
Broken Access Control bedeutet, dass die Anwendung nicht ausreichend prüft, WER auf WAS zugreifen darf. Die häufigste Form, IDOR (Insecure Direct Object Reference), erlaubt den Zugriff auf fremde Objekte allein durch Ändern einer ID im Request.
Wie der Angriff funktioniert
- Ein Objekt wird direkt über eine ID aus dem Request geladen (z. B. ?id=123) — ohne zu prüfen, ob es dem Anfragenden gehört.
- Fortlaufende, erratbare IDs machen das systematische Abgreifen fremder Datensätze trivial.
- Verwandt: fehlende Funktions-Zugriffsprüfung (eine eigentlich interne Aktion ist ohne Login erreichbar).
Beispiel
Der Unterschied ist die Eigentümer-/Rechteprüfung beim Laden:
// IDOR: lädt jedes Objekt per ID aus dem Request
$order = $this->orderRepository->findByUid($request->getArgument('id'));
// sicher: an den angemeldeten Nutzer gebunden
$order = $this->orderRepository->findOneByUidAndFeUser($id, $currentUser);
if ($order === null) { throw new AccessDeniedException(); }Mögliche Auswirkungen
- Massenhafter Abzug fremder Datensätze (Einsendungen, Bestellungen, Profile) — oft DSGVO-relevant.
- Unautorisierte Aktionen (ändern, löschen, exportieren).
- Keine Exploit-Werkzeuge nötig — eine hochgezählte ID reicht.
Worauf du in TYPO3 achten musst
In TYPO3 betrifft das vor allem Extbase-Plugins, Backend-Module und eigene Endpunkte. Der Core liefert die Bausteine für Zugriffsprüfungen — sie müssen aber bewusst eingesetzt werden.
Objekte nie blind per __identity/uid laden
Extbase mappt ein __identity im Request auf ein bestehendes Objekt (PropertyMapper). Wird eine uid aus Nutzereingabe ungeprüft geladen, entsteht IDOR. Immer gegen Eigentümer/Gruppe prüfen.
Eigentümerschaft explizit prüfen
Datensätze an den FE-User binden (z. B. feUser-Feld) und beim Laden filtern. Nur zu zeigen, was dem Anfragenden gehört — nicht erst nach dem Laden entscheiden.
enableFields & Storage-Pid respektieren
Repository-Queries berücksichtigen standardmäßig hidden/deleted/starttime/endtime (enableFields) und die storagePid. ->ignoreEnableFields(true) oder setRespectStoragePage(false) heben diese Schranken auf — nur sehr bewusst verwenden.
Backend-Zugriff serverseitig prüfen
Für BE-Funktionen $GLOBALS['BE_USER']->check() / isAdmin() nutzen und Modul-/Tabellenrechte prüfen. Sichtbarkeit im UI ist keine Zugriffskontrolle.
FE-Login + Gruppen statt 'unsichtbarer' URLs
Geschützte Inhalte über fe_group / Zugriffsschutz absichern. Eine nur 'versteckte' Seite oder ein nicht verlinktes Plugin ist nicht geschützt.
Schutzmaßnahmen
- Bei jedem Objektzugriff Eigentümer-/Rechteprüfung serverseitig erzwingen.
- IDs nicht als alleinige Autorisierung; unvorhersehbare Referenzen oder signierte Tokens.
- enableFields/storagePid nicht leichtfertig deaktivieren; BE-Rechte via BE_USER->check().
Interaktiv üben
In der Lernplattform kannst du diese Schwachstellenklasse an einer echten, isolierten TYPO3-Instanz nachvollziehen: