Angriffsziel UI: Benutzeraktionen, Passwörter und Clickjacking

Von Carsten Eilers

Das User Interface, auf dem Benutzeraktionen und -eingaben, beispielsweise zur Authentifizierung auf einer Webseite, getätigt werden, ist ein beliebtes Ziel für Cyberkriminelle, um Zugangsdaten zu erlangen. Das erste Kapitel dieses shortcuts befasst sich mit so genannten Logikfehlern, durch die sich Webanwendungen in bestimmten Situationen anders verhalten als erwartet. Der Autor legt dar, welche möglichen Schwachstellen es im Programmiercode gibt und wie diese verhindert werden können. Kapitel 2 wendet sich dem Themenfeld des Einloggens zu. Benutzername und Passwort reichen oft nicht mehr aus, um einen sicheren Zugang zu einer Webanwendung zu gewährleisten. Carsten Eilers stellt die verschiedenen Möglichkeiten der Authentifizierung vor und geht dabei besonders auf die Zwei-Faktor-Authentifizierung und die Nutzung von Einmalpasswörtern ein. Im dritten Kapitel beschreibt der Autor die Varianten des Clickjackings und nennt Maßnahmen, mit denen man diesem entgegenwirken kann.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 15. Jan. 2015
• ISBN: 9783868025323

Buchvorschau

GmbH

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