Broken Access Control (IDOR)

Einführung

Insecure Direct Object References (IDOR) sind eine Art von Zugriffskontrollschwachstelle, die auftritt, wenn eine Anwendung vom Benutzer bereitgestellte Eingaben verwendet, um direkt auf Objekte zuzugreifen. Wenn die Anwendung nicht ausreichend prüft, ob der Benutzer, der das Objekt anfordert, auch dazu berechtigt ist, kann ein Angreifer die Referenz (wie eine Datenbank-ID, einen Dateinamen oder eine Benutzer-ID in einer URL) manipulieren, um auf die sensiblen Daten anderer Benutzer zuzugreifen.

Der wichtige Unterschied ist, dass die Referenz an sich nicht die Schwachstelle darstellt. Die Schwachstelle liegt darin, dieser Referenz zu vertrauen, ohne zu prüfen, ob der aktuelle Benutzer überhaupt berechtigt ist, ihr zu folgen.

In diesem Lab schlüpfen Sie in die Rolle eines Sicherheitstesters, der eine lokale Web-Applikations-API bewertet. Sie beginnen damit, sich als Standardbenutzer zu authentifizieren, analysieren, wie die Anwendung auf Ihr Benutzerprofil verweist, und nutzen dann eine IDOR-Schwachstelle aus, um auf die privaten Daten anderer Benutzer, einschließlich eines Administrators, zuzugreifen.

Authentifizierung als Standardbenutzer

In diesem Schritt interagieren Sie mit einer lokalen Web-API, die auf Ihrem Rechner auf Port 5000 läuft. Um mit der Suche nach Schwachstellen in der Anwendung zu beginnen, müssen Sie sich zunächst als Standardbenutzer authentifizieren, um ein gültiges Sitzungstoken zu erhalten.

Wir haben die Anmeldedaten für einen Standardbenutzer namens Alice erhalten. Ihr Benutzername ist alice und ihr Passwort lautet password123.

Sie verwenden das Befehlszeilentool curl, um eine HTTP-POST-Anfrage an den Login-Endpunkt zu senden. curl ist ein leistungsstarkes Werkzeug zur Übertragung von Daten an oder von einem Server.

Führen Sie den folgenden Befehl in Ihrem Terminal aus, um sich anzumelden:

curl -X POST http://localhost:5000/api/login \
  -H "Content-Type: application/json" \
  -d '{"username": "alice", "password": "password123"}'

Lassen Sie uns diesen Befehl aufschlüsseln:

• -X POST gibt an, dass wir eine POST-Anfrage senden, die normalerweise zum Übermitteln von Daten wie Anmeldedaten verwendet wird.
• -H "Content-Type: application/json" teilt dem Server mit, dass die von uns gesendeten Daten im JSON-Format vorliegen.
• -d '...' enthält die eigentliche JSON-Daten-Payload mit Benutzername und Passwort.

Wenn die Anmeldedaten korrekt sind, sollten Sie eine Ausgabe ähnlich dieser sehen:

{"token": "Bearer alice_token", "user_id": "1001"}

Notieren Sie sich das token und die user_id. Das Token (Bearer alice_token) fungiert als Ihr digitaler Ausweis. Sie müssen es in zukünftigen Anfragen angeben, um nachzuweisen, dass Sie authentifiziert sind. Die user_id (1001) ist Ihre eindeutige Kennung in der Datenbank der Anwendung.

Analyse von Objektreferenzen (URLs/APIs)

Nachdem Sie nun als Alice authentifiziert sind, können Sie auf ihr Benutzerprofil zugreifen. In vielen Webanwendungen erfolgt der Zugriff auf Benutzerprofile über einen API-Endpunkt, der Ihr Authentifizierungstoken und eine Referenz auf das spezifische Objekt (in diesem Fall das Benutzerprofil), das Sie anzeigen möchten, erfordert.

Sie verwenden erneut curl, senden diesmal jedoch eine GET-Anfrage an den Endpunkt /api/profile. Sie müssen das Authentifizierungstoken in die HTTP-Header aufnehmen und Ihre user_id in der URL angeben.

Dies ist genau die Art von Muster, die in echten APIs vorkommt: Ein Token beweist, dass die Sitzung existiert, während ein Parameter das abzurufende Objekt auswählt. Sichere Anwendungen müssen diese beiden Konzepte durch Autorisierungsprüfungen miteinander verknüpfen.

Führen Sie den folgenden Befehl aus, um Alices Profil anzuzeigen:

curl -H "Authorization: Bearer alice_token" \
  "http://localhost:5000/api/profile?user_id=1001"

In diesem Befehl:

• -H "Authorization: Bearer alice_token" übergibt Ihren digitalen Ausweis an den Server.
• ?user_id=1001 ist ein Abfrageparameter, der an die URL angehängt wird. Dies ist die Direct Object Reference. Sie teilt dem Server genau mit, welcher Datenbankeintrag abgerufen werden soll.

Sie sollten eine JSON-Antwort erhalten, die Alices Profilinformationen enthält:

{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}

Beachten Sie, wie die Anwendung sich auf den Parameter user_id=1001 in der URL verlässt, um zu entscheiden, welche Daten zurückgegeben werden sollen. Eine sichere Anwendung würde überprüfen, ob der Benutzer, der mit dem Bearer alice_token verknüpft ist, tatsächlich berechtigt ist, die Daten für user_id=1001 einzusehen. Wenn die Anwendung diese Autorisierungsprüfung nicht durchführt, ist sie anfällig für IDOR.

Manipulation von Benutzer-IDs

In diesem Schritt testen Sie, ob die Anwendung die Zugriffskontrollen ordnungsgemäß durchsetzt. Sie sind derzeit als Alice authentifiziert, aber was passiert, wenn Sie den Server nach den Daten eines anderen Benutzers fragen?

Das ist die zentrale Frage der Autorisierung. "Bin ich eingeloggt?" und "Darf ich dieses Objekt lesen?" sind unterschiedliche Prüfungen, und deren Verwechslung führt direkt zu IDOR.

Nehmen wir an, es gibt einen weiteren Standardbenutzer namens Bob, dessen Benutzer-ID 1002 lautet. Wenn die Anwendung anfällig für IDOR ist, wird sie dem user_id-Parameter in der URL blind vertrauen, ohne zu prüfen, ob Alice die Berechtigung hat, Bobs Profil einzusehen.

Ändern Sie den user_id-Parameter in Ihrem vorherigen Befehl von 1001 auf 1002. Führen Sie den folgenden Befehl aus:

curl -H "Authorization: Bearer alice_token" \
  "http://localhost:5000/api/profile?user_id=1002"

Beobachten Sie die vom Server zurückgegebene Ausgabe:

{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}

Sie haben erfolgreich Bobs private Informationen abgerufen, einschließlich seiner E-Mail-Adresse und seines geheimen Schlüssels, während Sie weiterhin als Alice authentifiziert sind!

Dies bestätigt das Vorhandensein einer Insecure Direct Object Reference (IDOR) Schwachstelle. Der Server hat zwar geprüft, ob Sie eingeloggt sind (durch Validierung des Tokens), aber er hat versäumt zu prüfen, ob Sie autorisiert sind, auf das spezifische Objekt (Bobs Profil) zuzugreifen, das Sie angefordert haben.

Zugriff auf nicht autorisierte Daten

Nachdem Sie die IDOR-Schwachstelle bestätigt haben, können Sie den Angriff nun eskalieren, um auf hochsensible Informationen zuzugreifen. In vielen Systemen haben administrative Benutzer vorhersehbare IDs, wie 1, 0 oder 9999.

Für diese Anwendung lautet die Benutzer-ID des Administrators 9999. Durch Ausnutzung derselben IDOR-Schwachstelle können Sie versuchen, das Profil des Administrators zu extrahieren, das ein geheimes Flag enthält.

Um Ihre Erkenntnisse zu dokumentieren, leiten Sie die Ausgabe Ihres curl-Befehls in eine Datei namens flag.txt in Ihrem aktuellen Arbeitsverzeichnis (~/project) um.

Führen Sie den folgenden Befehl aus, um das Profil des Administrators abzurufen und zu speichern:

curl -H "Authorization: Bearer alice_token" \
  "http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt

Das Symbol > leitet die Ausgabe, die normalerweise auf Ihrem Bildschirm erscheinen würde, in die angegebene Datei um.

Um zu überprüfen, ob Sie die Daten des Administrators erfolgreich erfasst haben, lesen Sie den Inhalt der Datei mit dem Befehl cat:

cat ~/project/flag.txt

Sie sollten die Profildaten des Administrators sehen, einschließlich des geheimen Flags:

{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}

Herzlichen Glückwunsch! Sie haben erfolgreich eine IDOR-Schwachstelle ausgenutzt, um Zugriffskontrollen zu umgehen und sensible administrative Daten abzurufen.

Zusammenfassung

In diesem Lab haben Sie die Mechanismen von Insecure Direct Object References (IDOR) untersucht, einem kritischen Fehler in der Zugriffskontrolle. Sie begannen mit der Authentifizierung als Standardbenutzer und analysierten, wie die Anwendung über URL-Parameter auf Benutzerdaten verweist. Durch die Manipulation dieser Parameter haben Sie erfolgreich Autorisierungsprüfungen umgangen, um die privaten Profile anderer Benutzer einzusehen. Schließlich haben Sie den Angriff eskaliert, um sensible administrative Daten zu extrahieren.

Diese Übung unterstreicht, wie wichtig es ist, robuste Autorisierungsprüfungen auf der Serverseite zu implementieren. Anwendungen dürfen sich niemals allein auf vom Benutzer bereitgestellte Eingaben verlassen, um Zugriff auf Objekte zu gewähren; sie müssen immer überprüfen, ob der authentifizierte Benutzer das explizite Recht hat, auf die angeforderte Ressource zuzugreifen.