So finden und beseitigen Sie IDOR – ein Bildungsprogramm zu Schwachstellen für Pentester und Webentwickler

99 % von dem, was ich tue, sind vermeidbare Fehler. Heute werde ich über IDOR sprechen, eine der häufigsten und am einfachsten zu verwendenden Sicherheitslücken im Internet. Mit seiner Hilfe können Sie die Fotos anderer Leute in einem sozialen Netzwerk sehen oder einen Rabatt in einem Online-Shop erhalten, oder Sie können Tausende von Dollar an Bug Bountys verdienen.

Anhand praktischer Beispiele zeige ich, wie Hacker Fehler in der Geschäftslogik in Anwendungen finden und ausnutzen, und gebe praktische Ratschläge, wie diese in der Entwicklungsphase behoben werden können.

IDOR – was ist das und womit wird es gegessen?

Ich werde mit den Grundlagen beginnen. Die Webanwendung manipuliert bestimmte Entitäten. Auf der Website eines Online-Shops sind dies beispielsweise Produkte, Benutzer, Warenkörbe, Aktionscodes usw. Jede Instanz einer solchen Entität wird als separates Objekt behandelt, dem eine eigene Kennung zugewiesen wird. ID 483202, PID 6260 – jede Anwendung wird mit diesen Werten gefüllt.

Es wird davon ausgegangen, dass der Benutzer Objekte über die Schnittstelle innerhalb der Logik der Anwendung manipuliert. In diesem Fall zeigt die Anwendung nur die Objekte an, mit denen der Benutzer interagieren darf. Einem aufmerksamen Benutzer werden die Identifikatoren dieser Objekte jedoch beispielsweise in der Adressleiste auffallen. Ein Hacker wird definitiv versuchen, sie zu ändern. So können Sie unter Umgehung der Anwendungslogik und trotz der Verbote direkt auf andere Objekte zugreifen.

Diese Schwachstelle wird IDOR (Insecure direct object reference) genannt – eine unsichere direkte Objektreferenz. Es tritt auf, wenn drei Bedingungen gleichzeitig erfüllt sind:

  1. der Benutzer kann einen direkten Verweis auf ein internes Objekt oder eine interne Operation finden;

  2. der Benutzer kann die Parameter in diesem Link ändern;

  3. Die Anwendung gewährt Zugriff auf ein internes Objekt oder eine interne Operation, ohne die Rechte des Benutzers zu prüfen.

Nehmen wir als Beispiel den Link zu diesem Artikel: Darin ist die Kennung 686464 enthalten, die durch eine andere Zahl ersetzt werden kann. Zwei der drei Bedingungen sind erfüllt.

Wenn Sie die Zahlen durchgehen, werden Sie früher oder später einen Link zu einem anderen Entwurf erraten, zum Beispiel diesen hier: Wenn sich ein solcher Link öffnet, herzlichen Glückwunsch, Sie haben IDOR gefunden. Auf Habré geschieht dies nicht, da die dritte Bedingung für das Erscheinen von IDOR nicht erfüllt ist. Der korrekte Autorisierungsmechanismus funktioniert auf Habré.

Das Ändern einer URL ist ein klassisches Beispiel für ein IDOR, aber anfällige Kennungen werden nicht nur in der Adressleiste gefunden. Wenn du nimmst Statistiken zu Fehlerberichten auf HackerOnestellt sich heraus, dass IDORs am häufigsten in der REST-API, in GET-Parametern und im Text von POST-Anforderungen zu finden sind.

Risiken und Folgen von IDOR

Die Gefährlichkeit derartiger Schwachstellen hängt stark davon ab, welche Daten und welche Operationen damit dem Angreifer zur Verfügung stehen. Herkömmlicherweise wird IDOR in vier Typen unterteilt (in der Praxis überschneiden sie sich häufig):

1. Unbefugter Zugriff auf Daten

Manchmal bieten direkte Objektreferenzen Zugriff auf den Inhalt von Datenbanken: einzelne Felder oder interne Bezeichner, mit denen Sie SQL-Injections vorbereiten können.

Ich bin kürzlich auf einen ähnlichen Fehler auf dem Portal eines neuen sozialen Netzwerks gestoßen. Beim Aufrufen des Endpunkts GET /feed/gallery/uuid gab der Server die persönlichen Daten der Benutzer zurück: Telefonnummer und E-Mail-Adresse.

2. Durchführung nicht autorisierter Transaktionen

Durch Ändern Ihrer Benutzer-ID oder API-Schlüssel können Sie auf kostenpflichtige App-Funktionen zugreifen und sogar Befehle als Administrator ausführen.

In diesem Beispiel steht ohne Berechtigung die Methode DELETE /accounts/{uuid} zur Verfügung, mit der Sie ein beliebiges Benutzerkonto durch Angabe einer gültigen UUID löschen können. Dieser Identifier hat in der Regel eine hohe Entropie und ist nicht einfach per Brute Force zu erzwingen, aber wenn ein solcher IDOR mit anderen Schwachstellen kombiniert wird, ist es sehr gefährlich.

In diesem Fall war auf der untersuchten Ressource ein unbefugter Zugriff auf eine Reihe von Endpunkten möglich, die den Parameter page_size enthielten. Es ist für die Anzeige von Benutzerseiten verantwortlich. Die korrekte Änderung der Anfrage ermöglichte es, massenhaft und ohne Berechtigung Informationen über den Benutzer hochzuladen, einschließlich der für den Betrieb von IDOR erforderlichen UUID.

3. Verwalten von Anwendungsobjekten

Bei einigen IDORs können Sie Daten innerhalb der Anwendung bearbeiten. Diese Schwachstelle könnte es einem Angreifer ermöglichen, Sitzungsvariablen zu ändern, z. B. Berechtigungen zu eskalieren oder Zugriff auf eingeschränkte Funktionen zu erhalten.

Dies ist ein Screenshot aus dem Pentest eines der Lieferdienste. Es stellte sich heraus, dass in der Anwendung eine API verfügbar ist, die nur für Mitarbeiter des Unternehmens bestimmt ist. IDOR gab dem Kunden die volle Funktionalität eines Mitarbeiters, wie z. B. das Anzeigen des Status von Fahrzeugen und die Möglichkeit, neue Konten zu erstellen.

4. Direkter Dateizugriff

Mit dieser Art von IDOR können Sie die Ressourcen des Dateisystems manipulieren: Dateien hochladen und bearbeiten, kostenpflichtige Inhalte kostenlos herunterladen.

Einmal wurde ein solcher unbefugter Zugriff auf der Website einer Online-Schule gefunden – dort wurde der Zugriff auf Lehrpläne und Unterrichtsstunden ermöglicht. Um die Inhalte herunterzuladen, genügte es, den Routen zu folgen: /api/0/curriculum/lessons/ und /api/0/files//content.

Sammle sie alle! Oder wie IDOR gejagt wird

Um IDOR zu finden, fangen Hacker API-Anfragen ab und ersetzen sie durch neue Kennungen, indem sie beispielsweise einen Web-Proxy verwenden, BURP-Suite. Manchmal verlassen sie sich auf Glück und Brute-Force-IDs, aber es gibt elegantere Techniken, wie z. B. das Austauschen von Sitzungsbezeichnungen.

So finden Sie IDOR:

  1. Sie müssen zwei Benutzer erstellen und ihre Sitzungsbezeichnungen speichern.

    Dies kann ein Token oder eine Sitzungs-ID sein, bei der es sich um eine beliebige Zeichenfolge in der API handelt, die die Anwendung verwendet, um den angemeldeten Benutzer zu identifizieren.

  2. Der nächste Schritt besteht darin, sich als erster Benutzer anzumelden, eine Reihe von Aktionen in der Anwendung auszuführen und diese mithilfe eines Proxys aufzuzeichnen.

  3. Jetzt müssen wir uns den Datenverkehr ansehen und den API-Aufruf finden, der die Objekt-ID an den Server weitergibt.

  4. Sie müssen den Anruf wiederholen, abfangen, bearbeiten und mit dem Sitzungskennzeichen des zweiten Benutzers an den Server senden.

Wenn der Server daraufhin mit einem Autorisierungsfehler geantwortet hat, fehlt höchstwahrscheinlich die IDOR. Wenn das Back-End jedoch Daten über das Objekt zurückgibt, müssen Sie die Antworten mit den normalen und fehlerhaften Anfragen vergleichen. Wenn sie identisch sind, ist die Anwendung angreifbar.

In der BURP Suite werden solche Überprüfungen teilweise mithilfe von Plugins automatisiert: AuthMatrix oder Autorisieren. Sie beseitigen die Routine und ermöglichen es Ihnen, die Ergebnisse zu filtern (z. B. in Autorize mit dem Flag Scope items only und regulären Ausdrücken). Diese Plugins sind jedoch nur ein praktisches Werkzeug. Die Hauptsache bei einer solchen Fehlersuche ist Erfahrung und Verständnis dafür, wie die Anwendung funktioniert.

  • Sie müssen herausfinden, welche Rollen und Gruppen in der Anwendung bereitgestellt werden und wie sie interagieren.

    Was ist der Unterschied zwischen Manager, Fahrer und Administrator und welche Funktionen stehen ihnen jeweils zur Verfügung?

  • Es ist wünschenswert, eine Karte der Beziehungen zwischen Ressourcen zu erstellen.

    Wie hängen Bestellungen, Schecks und Waren zusammen? Kann ein Benutzer Bestellungen unter dem Namen eines anderen aufgeben?

  • Es lohnt sich, die Funktionen der REST-API zu erkunden.

    Dieses Regelwerk zwingt Entwickler dazu, nach einem Muster vorzugehen, das gegen sie verwendet werden kann. Angenommen, Sie finden einen Endpunkt, der eine REST-Ressource verfügbar macht.

GET /api/chats//message/

Versuchen Sie, GET durch eine andere HTTP-Methode zu ersetzen. Wenn das nicht funktioniert, fügen Sie einen HTTP-Header mit Inhaltslänge hinzu oder ändern Sie den Inhaltstyp.

Warum es so viele IDORs gibt

In den letzten Jahren waren IDORs überall, mit mehreren in einem, sogar einer kleinen Anwendung. Mir scheint, dass es dafür objektive Gründe gibt:

  1. Weitere Kennungen werden von Clients gesendet.

    In der Vergangenheit konnte der Server Benutzeraktionen direkt verfolgen, aber in modernen Anwendungen leiten Clients immer mehr Daten auf Anfrage über eine API weiter.

  2. Die alte IDOR-Abwehr wird nicht mehr verwendet.

    Entwickler haben häufig echte Objekt-IDs durch temporäre ersetzt, die nur für diesen Benutzer und eine Sitzung relevant sind. Dazu wurde im Backend eine eigene Tabelle angelegt, in der jedes Objekt eine temporäre Kennung hatte. Diese Praxis hat ihre Relevanz verloren, da sie nicht gut mit den Prinzipien der REST-API übereinstimmt. Außerdem sieht diese Schnittstelle nicht mehr vor, den Zustand des Clients (Stateless) aufzuzeichnen.

  3. Rollenbilder werden komplexer.

    Selbst wenn eine Anwendung über einen robusten Mechanismus zum Überprüfen von Benutzerrechten verfügt, muss sie richtig konfiguriert werden. Für einen Entwickler kann es schwierig sein zu wissen, ob Benutzer X Datei Y zur Verfügung hat, insbesondere wenn der Benutzer ein Regionalmanager ist, der zu einem von einem Dutzend Untertypen innerhalb des Rollenmodells gehört. Eine weitere Einstellung des Autorisierungsmechanismus erschwert das Missverständnis zwischen Entwicklern und Endbenutzern des Systems. Infolgedessen bleiben Benutzern oft redundante Optionen, nur um zu vermeiden, dass sie versehentlich die gewünschten Funktionen auswählen.

Verteidigung und Eliminierung von IDOR sind nicht dasselbe

Es gibt viele Empfehlungen im Netz, um IDOR zu bekämpfen, aber viele davon sind verwirrend. Die Autoren solcher Tipps listen oft Methoden auf, um das Risiko einer Schwachstelle zu mindern, und geben sie als Möglichkeiten aus, sie zu beheben. Ich meine Empfehlungen wie:

  • Verwendung zufälliger Identifikatoren.

    Die meisten Programmiersprachen stellen kryptografische Funktionen bereit, die mit hoher Entropie einen neuen Wert erzeugen. Wenn Sie sie verwenden, um Objektkennungen zu erstellen, wird es für Angreifer schwieriger, eine neue ID zu finden, um IDOR auszunutzen.

  • Die Verwendung von Hashes.

    Eine weitere Möglichkeit, das Ändern von Kennungen zu erschweren. Sie ist z. B. in angegeben Notiz OWASP. Hashes können jedoch erraten werden. Übrigens dekodiert Base64, das manchmal auch als solches verwendet wird, obwohl es keine Hash-Funktion ist, ohne Probleme.

  • Verwenden von JWT JSON-Web-Tokens.

    Solche Token schützen vor einigen Manipulationen von Benutzer-IDs, lösen jedoch keine Probleme mit Objekt-IDs.

  • Filtern von Benutzereingaben, bevor sie von der Anwendung verarbeitet werden, Validieren von Bereichen, Längen und Formaten.

    Die vielleicht nützlichste dieser Empfehlungen ist die richtige Konfiguration des Filters.

Keines dieser Verfahren löst jedoch das Problem der Zugriffskontrolle und eliminiert IDOR nicht. Sie machen das Problem nur noch schlimmer. Übrigens: Externe Sicherheitssysteme wie Web Application Firewalls schützen nicht vor dieser Art von Schwachstelle.

Tatsache ist, dass IDORs eng mit der Geschäftslogik der Anwendung verbunden sind. Die einzige Möglichkeit, IDOR zuverlässig zu entschärfen, besteht in der Feinabstimmung der Sitzungsverwaltung und der Überprüfung des Benutzerzugriffs auf Objektebene. Selbst wenn ein Angreifer den internen Link findet und ändert, erhält er auf diese Weise keinen unbefugten Zugriff.

Natürlich ist jede Anwendung anders. Es gibt keinen universellen Weg zur Implementierung der Zugriffskontrolle, aber in jedem Fall sollte dieser Mechanismus gut entworfen und nach bestimmten Mustern getestet werden.

Es lohnt sich, sich ein Szenario anzusehen, in dem ein Benutzer mit geringen Berechtigungen versucht, Aktionen auszuführen, die nur für Benutzer mit hohen Berechtigungen bestimmt sind. Das Verifizierungsschema ähnelt dem beim Hacken verwendeten.

  1. Melden Sie sich bei der Anwendung unter einem Konto mit den höchsten Berechtigungen an.

  2. Führen Sie eine Reihe von Aktionen in der Anwendung durch und zeichnen Sie API-Anforderungen mithilfe eines Proxys auf.

  3. Authentifizieren Sie sich bei der Anwendung mit einem weniger privilegierten Konto, um ein Token für den Authorization-Header zu generieren.

  4. Aufgezeichnete API-Anforderungen mit geändertem Titel unter Verwendung eines Benutzertokens mit niedrigen Rechten wiedergeben.

Der nächste Schritt besteht darin, Unit-Tests zu entwickeln und auszuführen, um Grenzfälle abzudecken – Situationen, in denen:

  • Der Benutzer ist nicht authentifiziert, z. B. fehlt der Autorisierungsheader oder ist ungültig.

  • Der Benutzer ist authentifiziert, aber nicht für die Ressource autorisiert.

Schließlich sind vollständige Integrationstests unter Berücksichtigung von Grenzfällen erforderlich. Beim Testen einer API ist es wünschenswert, jede Methode für jeden Endpunkt zu testen. Leider gibt es von IDOR keinen Königsweg – nur testen, testen und nochmals testen.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *