Horizontale Rechteausweitung

Was ist Horizontale Rechteausweitung?

Unsichere direkte Objektverweise entstehen, wenn zwei Prüfungen verwechselt werden: Die Sitzungsprüfung bestätigt die Identität des Aufrufers, aber niemand prüft, ob er den angeforderten Datensatz lesen darf. Sie öffnen in einer Finanz-App Ihren eigenen Kontoauszug, ändern eine Ziffer der ID und lesen mit Ihrer gültigen Sitzung den Kontostand und die Transaktionen einer fremden Person. Danach ergänzen Sie den Vergleich zwischen dem Eigentümer des Datensatzes und dem Nutzer der Sitzung. Stimmen sie nicht überein, gibt der Handler 403 zurück. Sie erkennen auch, warum UUIDs und Rate Limits nur zusätzliche Schutzmaßnahmen sind.

Was Sie lernen in Horizontale Rechteausweitung

• Authentifizierung (wer anfragt) und Autorisierung (ob dieser Aufrufer diese Ressource erreichen darf) unterscheiden und erkennen, welche Prüfung IDOR umgeht
• Die IDOR-Signatur erkennen: eine gültige Sitzung, viele verschiedene Ressourcen-IDs und erfolgreiche Antworten mit Daten vieler verschiedener Kontoinhaber
• Die Eigentümerprüfung als primäre Abwehr anwenden: Eigentümer der Ressource mit dem Nutzer der Sitzung vergleichen und bei Abweichung mit 403 ablehnen
• Erklären, warum zufällige UUIDs, Rate Limits und stärkere Passwörter jeweils als primäre Abwehr gegen IDOR versagen: Der Fehler ist die fehlende Autorisierung, nicht die Vorhersagbarkeit der IDs.
• Die Eigentümerschaft anhand der serverseitigen Sitzung entscheiden, statt anhand eines Werts, den der Aufrufer in URL, Body oder Header kontrolliert

Horizontale Rechteausweitung — Trainingsschritte

1. Eine normale Kundenansicht

   Sablefin ist eine Finanz-App, bei der sich jeder registrieren kann. Bob hat das mit einer Wegwerf-Identität getan und sieht sich nun wie jeder andere Kunde sein eigenes Konto an. Er öffnet seinen Monatsauszug. Nichts daran ist für ihn gesperrt: Es ist sein Konto, seine Daten, seine Anmeldung.

2. Die Anfrage beobachten

   Bevor Bob etwas ändert, will er die Anfrage sehen, mit der seine App diese Seite lädt. Er öffnet die Netzwerk-Tools des Browsers und lädt die Seite neu, damit der Aufruf zum Abrufen seines Kontoauszugs mitgeschnitten wird.

3. Der Endpunkt und die ID

   Die Netzwerk-Tools haben den Aufruf mitgeschnitten. Es ist eine einfache GET-Anfrage an die API für Kontoauszüge; die vollständige Adresse von Bobs Auszug endet mit einer einzigen ganzen Zahl.

4. Das Token, das seine Identität belegt

   Dieselbe mitgeschnittene Anfrage enthält Bobs Session-Token. Der Server liest es aus, um zu bestätigen, dass ein angemeldeter Kunde anfragt.

5. Eine Ziffer ändern

   Bob fasst die Oberfläche der App nicht mehr an. Er bearbeitet die mitgeschnittene Anfrage direkt, verringert die ID um eins und sendet sie mit seinem eigenen Token erneut. Liefert der Server einen fremden Kontoauszug, hat er die Eigentümerschaft nie geprüft, sondern darauf vertraut, dass die ID in der URL bestimmt, was er zurückgeben soll.

6. Das Konto einer anderen Person

   Anderer Name, andere Kontonummer, anderer Kontostand — und Bobs Token hängt weiterhin an der Anfrage. Der Server durfte diesen Auszug nicht an Bob ausliefern, tat es aber trotzdem. Eine benachbarte ID genügt, um den Fehler zu bestätigen. Alles Weitere erledigt ein zehnzeiliges Skript, das über Nacht den ID-Bereich durchläuft, während Bob schläft.

7. Wissenscheck

8. Der Alarm trifft ein

   Sie verantworten den Service für Sablefins Kundenkonten. Über Nacht hat die Anomalieerkennung eine Sitzung erkannt, die Kontoauszug um Kontoauszug über fremde Konten hinweg abrief. Security Operations hat Ihnen die Details per E-Mail geschickt.

9. Den Handler öffnen

   Öffnen Sie den Handler für Kontoauszüge und prüfen Sie, wie er entscheidet, was zurückgegeben wird.

10. Die Schwachstelle finden

    Der Handler lädt den Kontoauszug anhand der ID in der URL und gibt ihn zurück. Zwischen diesen beiden Zeilen fehlt die erforderliche Prüfung.