Dipl.-Inform. Carsten Eilers

Auch das folgende Beispiel stammt von Sumit Siddharth und Richard Dean. Eine einfache Messaging-Anwendung stellt folgende Funktionen bereit:

• Normale Benutzer können sich untereinander Nachrichten schicken
• Normale Benutzer können ihr eigenes Profil ändern
• Administratoren können die Profile anderer Benutzer ändern

Um eine Nachricht an einen Benutzer zu senden, wird der zuerst aus einer Liste ausgewählt. Die ID des ausgewählten Benutzers wird in einem POST-Request mit Session-Cookie an den Server geschickt. Danach kann die Nachricht eingegeben werden, die ebenfalls als POST-Request mit Session-Cookie an den Server geschickt wird.

Im zweiten Schritt wird die ID des Benutzers, an den die Nachricht geschickt werden soll, nicht übertragen, sie muss also in der Session des Benutzers auf dem Server gespeichert sein. Ein Angreifer hat also die Kontrolle über (mindestens) eine Session-Variable.

Das Absenden der Nachricht erfolgt nach folgendem Muster:

if ( isset($_SESSION['target_id']) ){
   // Nachricht an zuvor ausgewählten Benutzer senden
   $target  = $_SESSION['target_id'];
   $message = $_POST[‘message’];
   send_message($target, $message);
}
else {
   // Fehlermeldung "Kein Benutzer ausgewählt" ausgeben
   ...
}

Beim Ändern eines Benutzerprofils durch einen Administrator erfolgt die Auswahl des zu ändernden Profils analog zur Auswahl des Nachrichtenempfängers beim Versand einer Nachricht. Auch die ID des zu ändernden Profils wird im gleichen Parameter, target_uid, übertragen.

Daraus lässt sich ein Angriff konstruieren:

1. Der Angreifer ruft die Seite zur Änderung seines Profils auf.
2. In einem zweiten Fenster ruft er die Seite zum Verschicken einer Nachricht auf.
3. Dort wählt er einen Benutzer aus und schickt das Formular ab.
4. Nun löscht er in seinem Profil eines der erforderlichen Felder und klickt auf "aktualisieren".
5. Aufgrund des fehlenden notwendigen Parameters schlägt das Aktualisieren fehl - und die Seite zeigt die Informationen eines anderen Benutzers an: Dessen, der im 3. Schritt ausgewählt worden war.
6. Über die Password-Recovery-Funktion kann der Angreifer sich so Zugriff auf beliebige Accounts verschaffen.

Der Code zum Aktualisieren des Profils folgte folgenden Muster:

if ( isset($_SESSION['target_id']) ){
   // Änderung eines fremden Profils
   update_profile($_SESSION['target_id']);
} 
else {
   // Ändern des Profils des aktuellen Benutzers
   update_profile($_SESSION[‘uid']);
}

Die Entwickler waren davon ausgegangen, dass die Session-Variable target_id nicht von einem Angreifer manipuliert werden kann. Sie hatten übersehen, dass sie auch beim Versenden einer Nachricht verwendet wird und dabei vom Benutzer und damit auch einem Angreifer manipuliert werden kann.

Logikfehler finden

Logikfehler sind besonders oft dort zu finden, wo es "Brüche" in der Anwendung(sentwicklung) gibt:

• Stellen, an denen der Code verschiedener Entwickler miteinander kombiniert wird - zum Beispiel weil die Anwendung von mehreren Gruppen entwickelt wurde oder weil selbst geschriebener Code mit einem Framework kombiniert wird.
• Stellen, an denen nachträglich Funktionen ergänzt wurden.
• Stellen, an denen auf externe Dienste zugegriffen wird.

Wenn der Sourcecode der Webanwendung vorliegt, erkennt man verdächtige Stellen zum Beispiel

• an unterschiedlichen Coding-Stilen, beispielsweise weil Coding-Richtlinien missachtet oder verschiedene Coding-Richtlinien verwendet wurden.
• an fehlenden Framework-Elementen, durch die zum Beispiel Sicherheitsfunktionen versehentlich deaktiviert oder unbrauchbar gemacht werden.
• an komplexen Session-Verläufen - je komplexer der Ablauf, desto größer die Wahrscheinlichkeit für Fehler.
• an neu hinzugefügten Funktionalitäten.
• an Gemeinsamkeiten eigentlich unterschiedlicher Funktionen - immer, wenn Code erneut verwendet wird, stellt sich die Frage, ob es sich der Entwickler dabei mit dem Copy&Paste nicht zu einfach gemacht hat

Liegt der Sourecode nicht vor, hilft manchmal ein Blick in den Sourecode der Webseiten. Ändert sich darin die Formatierung auffällig, zum Beispiel von einem strukturierten Bereich zu einem Stück ohne jeden Zeilenumbruch, lohnt sich oft eine nähere Untersuchung. An solchen Stellen ist sehr wahrscheinlich unterschiedlicher Code für die Ausgabe verantwortlich und die Wahrscheinlichkeit für Fehler und damit Schwachstellen steigt gewaltig.

Ebenso verdächtig ist es, wenn ursprünglich vom Server stammende Daten an den Server zurück gesendet werden. Im obigen Beispiel könnte es beim Versand einer Nachricht gute Gründe geben, die im ersten Schritt an den Server gesendete Empfänger-ID als versteckten Parameter im folgenden Formular für die Eingabe der Nachricht zu integrieren statt sie auf dem Server zu speichern (wenn man sich dann auch fragen müsste, warum dann nicht Empfängerauswahl und Nachrichteneingabe auf einer Seite erfolgen).
Aber sowieso auf dem Server gespeicherte Daten an diesen zurück zu schicken wie im Beispiel der Preise im Warenkorb aus dem ersten Teil ist völlig überflüssig und meist Anzeichen für eine mögliche Schwachstelle.

In der nächsten Folge geht es weiter um Logikfehler in Webanwendungen.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Websecurity - XSS-Angriffe über XML

Websecurity - Angriffe über Logikfehler

Websecurity - Angriffe über Logikfehler, Teil 2

Websecurity - Logikfehler in der Authentifizierung

Websecurity - Logikfehler in der Authentifizierung und auf der Flucht

Websecurity - Logikfehler finden

Websecurity - Logikfehler vermeiden