Teil 3 – Wie man IDOR findet und testet

Sep. 12, 2025

—

von

Der erste Schritt: genauer hinschauen

Um eine IDOR-Schwachstelle zu entdecken, braucht es keine Profi-Hacker-Skills. Alles beginnt damit, die Kommunikation zwischen Browser oder App und dem Server zu beobachten. Jede Aktion – sei es das Laden einer Profilseite, das Bearbeiten eines Dokuments oder das Abrufen einer Bestellung – erzeugt HTTP-Requests. Genau dort verstecken sich die Hinweise.

Im Browser bieten sich die Entwicklertools an (Chrome, Firefox, Edge). Unter „Netzwerk“ sieht man alle Requests mit URL, Parametern, Methoden und Antworten. Schon das bloße Mitlesen hilft, verdächtige IDs oder Objektreferenzen zu finden.

Parameter-Manipulation in URLs

Der Klassiker: ein Request mit einer leicht veränderbaren ID.

https://shop.example.com/order?id=1001

Die Testmethode ist simpel: Zahl ändern.

1001 → eigene Bestellung
1002 → fremde Bestellung?

Falls ja, ist die Anwendung unsicher.
Das Gleiche gilt bei Pfadparametern:

/profile/42
/profile/43

Wenn beim Erhöhen oder Verringern der Zahl fremde Daten erscheinen, liegt eine IDOR-Schwachstelle vor.

APIs im Visier

Auch APIs sind anfällig. Ein Request könnte so aussehen:

GET /api/v1/messages/150 HTTP/1.1
Host: app.example.com
Authorization: Bearer eyJhbGciOi...

Ein erster Test: Die ID von 150 auf 151 ändern. Wenn die Antwort Daten enthält, die eigentlich zu einem anderen Nutzer gehören, ist die Zugriffskontrolle fehlerhaft.

In REST-APIs sind solche numerischen IDs besonders häufig. GraphQL-APIs haben ähnliche Risiken – hier gilt es, Query-Parameter oder Objekt-IDs zu manipulieren.

Formulare und versteckte Felder

Ein weiteres Einfallstor sind Formulare. Beispiel:

<form action="/updateProfile" method="POST">
  <input type="hidden" name="userid" value="42">
  <input type="text" name="email" value="alice@example.com">
  <button type="submit">Speichern</button>
</form>

Angreifer können mit den Entwicklertools das userid-Feld anpassen. Wird der neue Wert nicht serverseitig validiert, lassen sich fremde Konten ändern.

Tools für systematisches Testen

Neben den Browser-DevTools sind zwei Werkzeuge besonders nützlich:

Postman: Gut geeignet, um API-Requests zu reproduzieren und Parameter schrittweise anzupassen.
Burp Suite: Ein Proxy, der sämtlichen Traffic zwischen Browser und Server abfängt. Praktisch, um versteckte Felder, Cookies und Header zu analysieren. Mit dem „Repeater“-Modul lassen sich Requests schnell variieren.

Ein typischer Testablauf mit Burp Suite:

Login durchführen und Traffic mitschneiden.
Einen Request identifizieren, der eine ID enthält.
Den Request im Repeater öffnen.
Die ID systematisch erhöhen oder verringern.
Reaktionen beobachten: Fehler, fremde Daten, Redirects.

Worauf man achten sollte

Statuscodes: 403 oder 401 deuten auf Schutz hin, 200 kann ein Warnsignal sein.
Antwortgröße: Wenn sich beim Ändern von IDs die Größe ändert, steckt dahinter vielleicht ein anderer Datensatz.
Fehlermeldungen: Auch aussagekräftige Fehler („User not found“) können Hinweise geben.

Manchmal blockiert die Anwendung nicht sofort, gibt aber kleine Informationsschnipsel preis – auch das kann eine Schwachstelle sein.

Typische Stolperfallen beim Testen

Manche Apps verwenden undurchsichtige IDs (UUIDs, Hashes). Das erschwert das Testen, ist aber kein Allheilmittel – auch diese Werte können manchmal erraten oder durch Leaks gefunden werden.
Mobile Apps nutzen oft verschlüsselte Requests. Mit Tools wie Burp Suite und einem passenden Zertifikat lassen sie sich trotzdem untersuchen.
Nicht jeder Fund ist automatisch kritisch – entscheidend ist, ob unautorisierte Daten offengelegt oder verändert werden können.