Coders Conquer Security: Share & Learn Series: Unsichere direkte Objektreferenz

URLs sind unverzichtbar für die Navigation in all den Websites und Webanwendungen, die wir kennen und lieben. Ihre grundlegende Funktion ist es, zu identifizieren, wo sich Ressourcen befinden und wie sie abgerufen werden können. Während URLs für das Funktionieren des World Wide Web notwendig sind, können sie auch ein Sicherheitsrisiko darstellen, wenn sie nicht richtig gesichert sind.

In diesem Beitrag werden wir lernen:

• Was IDOR ist und wie Angreifer IDOR verwenden
• Warum IDOR gefährlich ist
• Techniken, die diese Sicherheitslücke beheben können

IDOR verstehen

Eine direkte Objektreferenz liegt vor, wenn ein bestimmter Datensatz (das "Objekt") innerhalb einer Anwendung referenziert wird. Er hat normalerweise die Form eines eindeutigen Bezeichners und kann in einer URL erscheinen.

Zum Beispiel könnten Sie etwas wie "?id=12345" am Ende einer URL bemerken. Die Zahl, 12345, ist ein Verweis auf einen bestimmten Datensatz. Sicherheitslücken schleichen sich ein, wenn die Zugriffskontrolle für einzelne Datensätze nicht vorhanden ist. Dadurch können Benutzer auf Datensätze und Daten zugreifen, die sie nicht sehen sollten. Dies ist ein Angriff, der relativ geringe Kenntnisse erfordert.

In diesem Fall würde ein Angreifer die ID in der URL auf 12344 ändern. In einer Anwendung, die für IDOR anfällig ist, könnte der Angreifer die Daten zu diesem Datensatz sehen.

Wie viel Schaden kann diese Art von Schwachstelle wirklich anrichten?

Wissen, warum IDOR gefährlich ist

Wenn Entwickler nicht vorsichtig sind, können sie ein System entwerfen, das Anwendungsdatensätze an verschiedenen Stellen anzeigt und durchsickern lässt. Ein Verstoß dieses Ausmaßes kann erheblich sein, insbesondere wenn sensible Daten oder PII betroffen sind.

Das australische Finanzamt richtete eine Website ein , um Unternehmen bei der Erhebung einer neuen Steuer zu unterstützen. Leider wurde sie mit der unerwünschten Funktion einer IDOR-Schwachstelle geliefert. Ein neugieriger Benutzer stellte fest, dass die URLs innerhalb der Website seine australische Geschäftsnummer (ABN) enthielten. Zufälligerweise ist dies eine leicht zu ermittelnde Nummer für jedes registrierte Unternehmen. Dieser Benutzer beschloss, die Nummern anderer Unternehmen in die URL einzufügen. So erhielt er deren Bankkontoinformationen und persönliche Daten!

Apple wurde kürzlich Opfer einer IDOR-Sicherheitslücke. Als das iPad zum ersten Mal veröffentlicht wurde, wurden 114.000 Kunden-E-Mail-Adressen geleakt. (Um fair zu sein, war es eher ein Fehler von AT&T).

Sie sehen, AT&T hat einen Dienst aufgebaut, der 3G-Konnektivität für iPads unterstützt. Das iPad sendete eine auf der SIM-Karte gespeicherte Kennung an den Dienst von AT&T. Der Dienst gab dann die E-Mail-Adresse des Benutzers zurück.

Leider waren diese Bezeichner einfach fortlaufende Ganzzahlen und damit leicht zu erraten. Angreifer iterierten durch die Bezeichner und stahlen die E-Mail-Adressen.

Ein weiterer Fehler war, dass der Dienst von AT&T versuchte, den Dienst zu "sichern", indem er die E-Mail-Adresse nur zurückgab, wenn der User-Agent-Header der Anfrage anzeigte, dass sie von einem iPad kam. Der User-Agent ist nur ein String-Wert, der leicht manipuliert werden kann.

IDOR-Schwachstellen können subtil und heimtückisch sein. Lassen Sie uns besprechen, wie man sie besiegen kann.

Beseitigen von IDOR

Zugriffskontrolle ist der Schlüssel zum Lösen von IDOR. Wenn ein Benutzer einen bestimmten Datensatz anfordert, stellen Sie sicher, dass er berechtigt ist, den angeforderten Datensatz anzuzeigen.

Die Verwendung von zentralisierten Autorisierungsmodulen ist der beste Weg, dies zu tun. Tools wie Spring Security bieten robuste und anpassbare Authentifizierung und Autorisierung für Anwendungen.

Fazit: Sie sollten ein Modul haben, auf das sich alle anderen Codes verlassen, um Berechtigungsprüfungen durchzuführen.

Eine weitere gängige Abschwächung ist die Verwendung von Surrogat-Referenzen. Anstatt die tatsächlichen Bezeichner der Datenbankdatensätze in Ihren URLs zu verwenden, können Sie zufällige Zahlen erstellen, die auf die tatsächlichen Datensätze zurückverweisen.

Die Verwendung von Surrogat-Referenzen stellt sicher, dass ein Angreifer nicht an einen Datensatz gelangen kann, indem er einfach den nächsten gültigen Bezeichner errät.

Und schließlich sollten Sie sich nicht auf etwas verlassen, das der Benutzer manipulieren kann, um eine Autorisierung zu erhalten. AT&T hat versucht, den User-Agent-Header zu verwenden, um seinen Dienst zu autorisieren. Verlassen Sie sich nicht auf HTTP-Header, Cookies oder GET- und POST-Parameter.

Mit diesen Abhilfemaßnahmen gehört IDOR der Vergangenheit an.

Sichern Sie Ihre Referenzen

Unsichere direkte Objektreferenzen sind eine der am einfachsten auszunutzenden Schwachstellen. Lassen Sie nicht zu, dass sie sich an Sie heranschleichen, wenn Sie es am wenigsten erwarten. Prüfen Sie immer, ob die Benutzer autorisiert sind. Verwenden Sie keine echten Datenbankbezeichner. Verlassen Sie sich bei der Autorisierung nicht auf benutzergesteuerte Daten.

Erweitern Sie Ihre Kenntnisse, indem Sie sich unsere Lernressourcen ansehen. Wenn Sie in der Sprache Ihrer Wahl üben, wie Sie IDOR-Schwachstellen entschärfen können, werden Sie keine Probleme haben, dieses Problem in Ihren Produktionscodebasen zu finden und zu beheben. Sie können Ihr neu erworbenes Verteidigungswissen auch mit einer kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, sich jetzt gegen IDOR-Angriffe zu verteidigen? Gehen Sie auf die Plattform und fordern Sie sich kostenlos heraus: [Hier starten]