Wenn Sie heute eine Website veröffentlichen, vergehen kaum ein paar Minuten, bis sie das erste Mal angegriffen werden. Diese Artikelserie beschäftigt sich mit den OWASP Top 10, den zehn meisten Sicherheitsrisiken, und gibt Tipps, wie sie sich und ihre Produkte schützen können.

Diese Serie besteht aus den folgenden Artikeln:

• Teil 1: Injection
• Teil 2: Fehler in Authentifizierung und Session-Management
• Teil 3: Cross-Site Scripting (XSS)
• Teil 4: Unsichere direkte Objektreferenzen (dieser Artikel)
• Teil 5: Sicherheitsrelevante Fehlkonfiguration
• Teil 6: Verlust der Vertraulichkeit sensibler Daten
• Teil 7: Fehlerhafte Autorisierung auf Anwendungsebene
• Teil 8: Cross-Site Request Forgery (CSRF)
• Teil 9: Nutzung von Komponenten mit bekannten Schwachstellen
• Teil 10: Ungeprüfte Um- und Weiterleitungen

Unsichere direkte Objektreferenzen

Auf Platz 4 der OWASP Top 10 sind unsichere direkte Objektreferenzen. Eine direkte Objektreferenz ist ein Schlüssel, der auf einen spezifischen Datenbankeintrag verweist. Oftmals werden dazu inkrementierende Zahlen verwendet, aber auch natürliche Schlüssel wie der Benutzername oder andere eindeutige Werte wie die AHV Nummer.

Ein Problem liegt dann vor, wenn eine solche unsichere direkte Objektreferenz in einer URL vorkommt und das ändern der Referenz in der URL einen Datensatz zurückgibt, für den der Benutzer keine Berechtigung hat. Sowohl Zahlen als auch Werte wie Benutzernamen kann man durchprobieren, möglicherweise auch automatisiert. Andere Werte wie die AHV Nummer kann man herausfinden.

Dass unsichere direkte Objektreferenzen ein Problem sind, hat der Finanzdienstleister Citigroup im Jahr 2011 erfahren müssen. Hacker ist es damals gelungen, durch einfache Manipulation der URL an Kontodaten von 200'000 Kunden zu gelangen.

Um unsichere direkte Objektreferenzen zu verhindern, ist eine korrekt implementierte Zugriffskontrolle das beste Mittel. Es ist auch das einzige Mittel, das wirklich funktioniert, sofern es klar definierte Regeln gibt, wer auf welche Ressourcen zugreifen darf und das auch entsprechend getestet ist. Allerdings sollte man es nicht dabei belassen. Der Einsatz von indirekten Objektreferenzen ist ganz klar zu empfehlen.

Eine indirekte Objektreferenz unterscheidet sich deutlich von der direkten Objektreferenz. Eine indirekte Objektreferenz ist ein absolut zufällig gewählter Wert. Zudem ist sie nur für den aktuellen Benutzer und nur temporär für einen bestimmten Zeitraum gültig, beispielsweise während einer Session. Die indirekte Objektreferenz versteckt die unsichere direkte Objektreferenz vor dem Benutzer und macht ein durchprobieren unmöglich.

Angenommen, ein Benutzer erstellt drei Objekte und hat jeweils die Möglichkeit, diese Objekte im Browser zu bearbeiten. Die Objekte haben in der Datenbank die Schlüssel 35, 36 und 37 erhalten. Bei unsicheren direkten Objektreferenzen sähen die URLs folgendermassen aus:

https://domain/objects/edit?id=35
https://domain/objects/edit?id=36
https://domain/objects/edit?id=37

Gut möglich, dass der Benutzer auf die Idee kommt, die gleiche URL mal mit der Zahl 20 zu versuchen. Durch den Einsatz einer indirekten Objektreferenz sehen die URLs beispielsweise so aus:

https://domain/objects/edit?id=8C1LY4RPPMp4nyJU
https://domain/objects/edit?id=hqjyVJSKvETrIjo4
https://domain/objects/edit?id=wQwhdhdlS8KaYKsX

Indirekte Objektreferenzen sind eine sehr gute Sache. Am wichtigsten ist jedoch die korrekte Implementierung und Verwendung der Zugriffskontrolle.

Ist Ihre Anwendung sicher? Nebst der in diesem Blog beschriebenen Möglichkeiten gibt es viele weitere Strategien, sich gegen Angreifer zu verteidigen. Gerne beraten ich Sie in Sicherheitsfragen oder führe ein Security Review in Ihrem Projekt durch. Kontaktieren Sie mich unverbindlich, um Ihre dringlichsten Fragen zu besprechen.