© DrHitch/Shutterstock.com
Angriffsziel UI

1 Angriffe über Logikfehler


Logikfehler sind äußerst unschön. Das fängt schon mit ihrer Beschreibung an, die allgemein gehalten gar nicht einfach ist. Beim Auftreten eines Logikfehlers verhält sich die Anwendung in einem bestimmten Status anders, als eigentlich erwartet wird. Zum Beispiel könnte ein Logikfehler dazu führen, dass der Arbeitsfluss manipuliert und ein eigentlich notwendiger Schritt übersprungen werden kann. Solche Schwachstellen entstehen meist, weil bei der Entwicklung mögliche externe Einflüsse (und insbesondere keine absichtlichen, bösartigen Manipulationen) auf den Ausführungspfad gar nicht oder zumindest nicht ausreichend berücksichtigt wurden.

Der Preis kann geändert werden

Ein klassisches Beispiel ist ein Bestellvorgang, bei dem der Preis der Ware manipuliert werden kann. Es ist normal, dass der Server den Preis an den Client sendet, er muss dem Kunden ja angezeigt werden. Wird er bei der Bestellung aber als versteckter Parameter zurück an den Server übertragen, ist das verdächtig. Wieso sollte der Client dem Server den Preis mitteilen, den der doch kennt? Mit etwas Glück ist das nur eine überflüssige Datenübertragung. Es kann aber auch eine gefährliche Schwachstelle dahinter stecken, und zwar wenn dieser manipulierte Preis von der Webanwendung für den weiteren Bestellablauf verwendet wird. Wenn die Waren dann ohne weitere Prüfung ausgeliefert werden, kann das für den Shopbetreiber teuer werden.

Ja, wo stecken sie denn?

Für die Erkennung von Logikfehlern ist das Verständnis der Anwendung nötig, sie lassen sich daher im Allgemeinen mit automatisierten Tools nicht erkennen. Denn kein noch so aufwändig programmiertes Tool kann erkennen, ob ein Schritt in einem Arbeitsablauf übersprungen werden kann/darf oder nicht. Logikfehler können daher nur durch manuelle Tests gefunden werden. Und da dabei alle Schritte zumindest aller potenziell gefährlichen Arbeitsabläufe meist mehrmals durchlaufen werden müssen, ist das aufwändig und fehleranfällig.

Von der Theorie zum praktischen Beispiel

Das obige Beispiel ist schön, aber auch einfach. Wie wäre es mit einem etwas komplizierteren? Vielleicht erinnern Sie sich noch an die kleine Webanwendung, die in den vorherigen Folgen des Securityworkshops als Beispiel diente. Wenn nicht, ist es auch nicht schlimm. Die Anwendung dient nur dazu, Texte zu erfassen und wieder auszugeben, außerdem gibt es eine rudimentäre Benutzerverwaltung, die zwischen normalen Benutzern (die Texte nur lesen dürfen), Autoren (die Texte auch verfassen und eigene Text ändern dürfen) und Administratoren (die auch die Texte anderer Autoren ändern dürfen) unterscheidet.

Möchte ein Administrator den Text eines anderen Benutzers ändern, wählt er zuerst den Benutzer aus einer Liste mit allen existierenden Benutzern aus. Die ID des ausgewählten Benutzers wird an den Server gesendet, der sie in der Sessionvariable ziel_id speichert. Danach wird dem Administrator eine Liste von den von diesem Benutzer erstellten Texten angezeigt, aus denen er dann einen Text zum Ändern auswählen kann. Der Code zur Auswahl des zu ändernden Texts folgt dem Muster in Listing 1.1.

if ( isset($_SESSION['ziel_id']) ){
// Änderung eines fremden Texts:
// Auflisten der Texte des Benutzers mit der ID $_SESSION[ziel_id']
...
}
else {
// Änderung eines eigenen Texts
// Auflisten der Texte des aktuellen Benutzers
...
}
// Bearbeiten des ausgewählten Texts
...

Listing 1.1

Diese Anwendung funktioniert zur vollsten Zufriedenheit der Entwickler und enthält auch keine Schwachstellen. Nun wird sie um eine Funktion zum gemeinsamen Arbeiten an einem Text erweitert.

Um einem bestimmten Benutzer Änderungen an einem neuen Text zu erlauben, wird zuerst der Benutzer aus einer Liste mit allen existierenden Benutzern ausgewählt. Die ID des gewählten Benutzers wird an den Server gesendet, der sie in der Sessionvariable ziel_id speichert.

Danach kann wie bei einem normalen Blogeintrag der Text eingegeben werden, der dann an den Server geschickt wird. Der Server speichert den Text zusammen mit der Information, welcher Benutzer ihn außer dem Autor ändern darf, in der Datenbank. Loggt sich der betreffende Benutzer später ein, wird ihm der neue Text zusätzlich zu seinen eigenen Texten angezeigt. Das Speichern des Texts erfolgt nach dem Muster in Listing 1.2.

if ( isset($_SESSION['ziel_id']) ){
// Text für den zuvor ausgewählten Benutzer änderbar speichern
...
}
else {
// Fehlermeldung, dass kein Benutzer ausgewählt wurde, ausgeben
...
}

Listing 1.2

So weit, so gut. Oder besser gesagt schlecht. Denn durch die neue Funktion ist eine Schwachstelle entstanden, mit deren Hilfe sich ein Angriff konstruieren lässt:

  1. Ein bösartiger Benutzer wählt einen Benutzer aus, mit dem er angeblich einen Text gemeinsam bearbeiten möchte. Jetzt ist in $_SESSION['ziel_id'] die ID dieses Benutzers gespeichert.
  2. Jetzt ruft er die Seite zum Ändern von Texten auf. Da $_SESSION['ziel_id'] nicht leer ist, wird ihm nicht, wie eigentlich vorgesehen, die Liste mit seinen eigenen Texten, sondern die Liste mit den Texten des betreffenden Benutzers angezeigt, aus denen er dann einen zum Ändern auswählen kann.

Worin liegt hier das Problem? Es wird davon ausgegangen, dass die Sessionvariable ziel_id nicht von einem normalen Benutzer und damit auch nicht von einem Angreifer manipuliert werden kann. Das war so lange korrekt, bis die Funktion zum gemeinsamen Bearbeiten eines Texts hinzugefügt wurde, die die gleiche Variable verwendet.

So etwas gibt es doch gar nicht!

Sie denken jetzt sicher „So etwas gibt es doch gar nicht, das ist doch konstruiert!“ Da ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang