Direkte unsichere Objektreferenz (IDOR)

Beispiel Szenarien

Der klassische IDOR-Angriff tritt auf, wenn der Server nur überprüft, ob der Benutzer authentifiziert ist, nicht jedoch, ob er autorisiert ist, auf eine Objektreferenz zuzugreifen. In einem typischen Ablauf:

1. Meldet sich der Angreifer als normaler Benutzer an.
2. Findet eine URL, ein Formularfeld oder eine Datei, die auf eine Benutzer- oder Ressourcen-ID verweist (z. B. 1234).
3. Ändert die ID in einen anderen Wert (z. B. 1233).
4. Erhält unbefugten Zugriff auf die Daten eines anderen Benutzers.

In den folgenden Abschnitten werden wir einige konkrete Beispiele für diesen Angriff untersuchen.

Manipulation der URL

Ein häufiger Typ von IDOR-Angriff betrifft die Manipulation von direkten Objektreferenzen in der URL. Die "1234" in den folgenden URLs ist ein Identifikator für den Datensatz des Benutzers in der Datenbank des Servers. Wenn ein Angreifer diese Zahl in eine andere Zahl (zum Beispiel "1235") ändert und auf die Informationen eines anderen Benutzers zugreift, ist Ihre Anwendung anfällig für direkte unsichere Objektreferenz.

# The attacker is logged in as user 1234
https://example.org/user/id/1234

# The attacker changes the id in the URL and gains access to a different user
https://example.org/user/id/1235

Im folgenden Express-Code steht der in der URL angegebene Wert als req.params.id zur Verfügung, und wir verwenden diesen Wert, um den entsprechenden Datensatz in der Datenbank abzurufen. Wir überprüfen auch, ob die Anfrage von einem authentifizierten Benutzer stammt, indem wir die isAuthenticated-Funktion aufrufen. Kritisch ist jedoch, dass wir nicht überprüfen, ob die ID des authentifizierten Benutzers mit der ID in der URL übereinstimmt, und dies ermöglicht einem authentifizierten Benutzer (dem Angreifer), eine Seite für einen anderen authentifizierten Benutzer (das Opfer) abzurufen.

app.get("/user/id/:id", (req, res) => {
  const user = db.users.find(req.params.id);
  if (req.isAuthenticated()) {
    // Authentication is not enough!
    res.render("user", { user });
  }
});

Stattdessen sollten Sie Regeln implementieren, um den Zugriff auf Benutzerinformationen zu autorisieren. Zum Beispiel sollte die Benutzerseite nur gerendert werden, wenn die ID des angemeldeten Benutzers mit der angeforderten Benutzer-ID übereinstimmt. Andernfalls geben Sie eine HTTP 401 Unauthorized-Antwort zurück.

app.get("/user/id/:id", (req, res) => {
  const user = db.users.find(req.params.id);
  if (req.isAuthenticated() && req.session.userId === req.params.id) {
    res.render("user", { user });
  } else {
    return res.status(401).json({ message: "Unauthorized" });
  }
});

Dokumentenmanipulation

Ähnlich wie bei der URL-Manipulation kann der Dokumenteninhalt einer Seite von einem Angreifer durch das Ändern von Werten von <form>-Elementen, wie Radiobuttons, Kontrollkästchen oder (versteckten) <input>-Elementen in den Entwicklertools des Browsers, manipuliert werden. Zum Beispiel überträgt Ihre Anwendung möglicherweise die Benutzer-ID nicht in der URL, sondern übergibt die Benutzer-ID in einem versteckten Formularelement:

<form action="updateUser" method="POST">
  <input type="hidden" name="user_id" value="1234" />
  <button type="submit">Update profile</button>
</form>

Wenn keine serverseitige Zugriffskontrolle durchgeführt wird, kann der Angreifer den user_id-Wert im versteckten <input>-Element auf eine andere Benutzer-ID ändern und möglicherweise das Profil ohne Autorisierung ändern.

Dateizugriff

Ein Spezialfall von IDOR-Angriffen ist der Zugriff auf Dateien oder Verzeichnisse, die nicht durch Zugriffskontrollen geschützt sind. Wenn Sie zum Beispiel einen Ordner für PDF-Dateiuploads bereitstellen und die Uploads fortlaufend benannt werden, kann ein Angreifer die Dateinamen erraten und sie alle herunterladen, wenn keine Zugriffskontrolle vorhanden ist. Potenziell können auch andere Dateien in ungeschützten Verzeichnissen, wie Serverkonfigurationsdateien, abgerufen werden, was zu zusätzlichen Schwachstellen führen könnte.

https://example.org/static/pdfs/1.pdf
https://example.org/static/pdfs/2.pdf

Abwehrmaßnahmen gegen IDOR

Zugriffskontrolle für jedes Objekt

Die wichtigste Maßnahme gegen IDOR-Angriffe ist die Implementierung von serverseitigen Zugriffskontrollen für jedes Objekt, auf das Benutzer zugreifen möchten. Vergewissern Sie sich stets, dass der authentifizierte Benutzer das Recht hat, auf das angezielte Objekt zuzugreifen oder Handlungen darauf auszuführen.

Komplexität der Identifikatoren

Stellen Sie sicher, dass Identifikatoren für Ressourcen nicht von einem Angreifer erraten werden können. Geben Sie keine persönlich identifizierbaren Informationen (PII) wie Benutzernamen oder E-Mail-Adressen in der URL preis. Verwenden Sie stattdessen ein eindeutiges, nicht erratbares Token, um den Benutzer zu repräsentieren. Sie können komplexere IDs als Primärschlüssel verwenden, wie UUIDs, und es erschweren, gültige Werte zu erraten. Dies verringert jedoch nur die Wahrscheinlichkeit, gültige IDs zu erraten, und ersetzt nicht die Notwendigkeit einer ordnungsgemäßen Zugriffskontrolle.

Zusammenfassung der Abwehrmaßnahmen

• Verifizieren Sie immer, dass der authentifizierte Benutzer autorisiert ist, auf das Objekt zuzugreifen oder es zu verändern.
• Vermeiden Sie, vorhersehbare, fortlaufende oder sensible Objekt-Identifikatoren (wie Benutzer-IDs oder E-Mail-Adressen) preiszugeben.
• Verwenden Sie komplexere IDs, die schwerer vorhersehbar sind (zum Beispiel UUIDs).

Siehe auch

• OWASP: Insecure Direct Object Reference Prevention Cheat Sheet