Unsichere direkte Objektreferenz (IDOR)
Erlaubt Angreifern, auf Daten anderer Benutzer zuzugreifen, indem Identifikatoren manipuliert werden.
Was ist diese Schwachstelle?
Unsichere direkte Objektreferenz (IDOR) ist eine Schwachstelle, bei der eine Anwendung interne Objektreferenzen (wie Datenbank-IDs, Dateinamen oder Schlüssel) in URLs oder Parametern offenlegt und nicht überprüft, ob der anfragende Benutzer berechtigt ist, auf dieses spezifische Objekt zuzugreifen. Dies erlaubt es Angreifern, auf Daten anderer Benutzer zuzugreifen, indem sie einfach eine ID oder Referenz in der Anfrage ändern.
Wie nutzt ein Angreifer dies aus?
Angreifer finden IDOR, indem sie Muster in URLs und API-Endpunkten identifizieren, die sequenzielle oder vorhersagbare Identifikatoren verwenden. Zum Beispiel kann /api/user/42/profile zu /api/user/43/profile geändert werden, um auf das Profil eines anderen Benutzers zuzugreifen. Sie zählen IDs systematisch auf (1, 2, 3...) oder verwenden bekannte Referenzwerte. In WordPress-Plugins betrifft IDOR häufig benutzerdefinierte Endpunkte, die Daten basierend auf benutzergelieferten IDs abfragen, ohne den Besitz zu überprüfen.
Mögliche Konsequenzen
- Einsehen privater Daten, Profile und persönlicher Informationen anderer Benutzer
- Ändern oder Löschen von Inhalten, Einstellungen oder Bestellungen anderer Benutzer
- Herunterladen von Dateien anderer Benutzer (Rechnungen, Uploads, Berichte)
- Zugriff auf Admin-Only-Ressourcen durch Erraten oder Aufzählen von Admin-Benutzer-IDs
- Verletzung von Datenschutzvorschriften (DSGVO) durch unbefugten Datenzugriff
- Finanzbetrug durch Zugriff auf Zahlungsinformationen oder Bestellungen anderer Benutzer
Wie schützen Sie sich
- Immer überprüfen, ob der authentifizierte Benutzer das angeforderte Objekt besitzt oder darauf zugreifen darf
- Indirekte Referenzen (UUIDs oder zufällige Tokens) statt sequenzieller Datenbank-IDs verwenden
- Ordnungsgemäße Autorisierungsprüfungen (current_user_can() + Besitzüberprüfung) auf jedem Endpunkt implementieren
- Sich niemals auf Verschleierung verlassen – davon ausgehen, dass Angreifer jede ID ausprobieren werden
- WordPress Capabilities und Besitzmuster konsequent verwenden
- Zugriffe protokollieren und überwachen, um Aufzählungsversuche zu erkennen
Wie finden Angreifer diese Schwachstelle?
Angreifer identifizieren IDOR, indem sie beobachten, wie die Anwendung Objekte in URLs, Formularen und API-Aufrufen referenziert. Sie prüfen auf numerische IDs (post_id=5, user_id=12) und testen benachbarte Werte. Automatisierte Tools wie Burp Suite können Antworten für verschiedene IDs vergleichen, um Datenlecks zu identifizieren. Sie testen sowohl direkten Zugriff (GET /resource/ID) als auch Modifikation (POST/PUT/DELETE), um sowohl Lese- als auch Schreib-IDOR-Schwachstellen zu finden.
Beispiel-CVEs aus unserer Datenbank
CartFlows <= 1.11.11 - Insecure Direct Object Reference to Arbitrary Post Deletion
WooCommerce Eway Gateway <= 3.5.0 - Insecure Direct Object Reference
JVM WooCommerce Wishlist <= 1.2.6 - Insecure Direct Object Reference
WPFunnels <= 2.7.15 - Insecure Direct Object Reference
Multivendor Marketplace Solution for WooCommerce <= 3.7.3 - Insecure Direct Object Reference
... und 228 weitere in unserer Datenbank
Typische Auswirkung
Unbefugter Datenzugriff, Datenmanipulation, Datenschutzverletzung.
Empfohlene Maßnahme
the affected plugin auf die neueste Version aktualisieren. Ordnungsgemäße Autorisierungsprüfungen für alle Objektzugriffe implementieren.
Ist Ihre WordPress-Seite von dieser Art von Schwachstelle betroffen?
Jetzt Ihre Seite scannen