entwickler.com

In dieser Folge von About Security lernen Sie einige weitere Schwachstellen in Webanwendungen kennen. Wie bei den bisher vorgestellten Schwachstellen geht die Gefahr auch dabei von gar nicht oder nicht ausreichend geprüften Benutzereingaben aus.

Formulare zum Senden einer E-Mail

Werden Benutzereingaben Bestandteil von E-Mail-Headern, z.B. From: oder To:, können darüber weitere Empfänger eingeschleust werden: beim To:-Header durch einfaches Anfügen, beim From:-Header durch Einschleusen einer To:-, Cc:- oder Bcc:-Zeile. Wie beim Protokoll HTTP wird auch in E-Mails das Ende einer Header-Zeile mit CRLF gekennzeichnet (RFC 822). Daher darf CRLF nicht Bestandteil eines Header-Werts sein. Es gibt jedoch eine Ausnahme: Um lange Zeilen umbrechen zu können, wird CRLF, gefolgt von einem Leerzeichen oder einem Tabulator, wie das Leerzeichen beziehungsweise der Tabulator behandelt. Da in den meisten Formularen für E-Mail-Adressen nur eine Zeile vorgesehen ist, kann dieser Spezialfall normalerweise unberücksichtigt bleiben und alles ab einem CRLF aus der Eingabe gelöscht werden. Falls der Standard exakt eingehalten werden soll, können die Eingaben entsprechend den Vorgaben in RFC822 ausgewertet werden, sodass nur zulässige Header-Zeilen akzeptiert werden.

Aufruf von Shell-Befehlen

Benutzereingaben, die direkt als Parameter für Shell-Befehle verwendet werden, können zur Ausführung weiterer Befehle ausgenutzt werden. Daher ist es keine gute Idee, Befehle wie z.B. ping oder traceroute über eine Weboberfläche zugänglich zu machen und die Parameter direkt zu übergeben. Ein Angreifer kann beispielsweise unter Unix-artigen Betriebssystemen beliebige weitere Befehle hinter einem ";" anfügen. Entweder müssen alle gefährlichen Zeichen aus der Eingabe ausgefiltert werden oder es dürfen nur zulässige Zeichen akzeptiert werden. Wie schon bei der Verhinderung von Cross-Site Scripting und SQL Injection ist es meist einfacher und sicherer, mit einer Positivliste zu arbeiten.

Wechsel des aktuellen Benutzers

Wird der aktuelle Benutzer ausschließlich anhand einer Benutzerkennung in dem URL erkannt, kann ein Benutzer durch Manipulation des Parameters die Identität eines anderen Benutzers annehmen. Ebenso verhält es sich bei einer Übertragung als Cookie oder POST-Parameter, es ist lediglich etwas mehr Aufwand nötig. Ein weiterer Nachteil dieser Methoden: Ein einfaches erneutes Laden der entsprechenden Seite reicht in der Regel aus, um den Status des jeweiligen Benutzers zu erlangen. Daher sollte die Identifikation der Benutzer immer auf mehreren Faktoren aufbauen. Nur weil ein Benutzer sich ordnungsgemäß angemeldet hat, bedeutet das nicht, dass die nächste Anfrage vom selben Webbrowser auch vom selben Benutzer stammt. Ein typisches Szenario ist ein Webbrowser in einem Internet-Cafe: Ein Benutzer kann die History-Funktion des Browsers benutzen, um vom vorherigen Benutzer besuchte Seiten anzusteuern. Werden dabei auch Authentifizierungsdaten übertragen, ist der neue Benutzer danach auf dem Webserver als der vorherige Benutzer angemeldet.

Manipulation von Onlinebestellungen

Werden in einem Webshop Benutzereingaben ohne weitere Prüfung zur Erstellung von Rechnungen verwendet, kann durch die Manipulation von zum Beispiel Preisen, Rabatten oder Versandkosten der Rechnungsbetrag gesenkt werden. Verläuft die gesamte Rechnungsstellung automatisiert, fällt eine derartige Manipulation unter Umständen überhaupt nicht auf. Entsprechende Daten dürfen daher nie aus den Benutzereingaben übernommen werden, sondern müssen auf dem Server der Datenbank entnommen und/oder dort berechnet werden.

Gefährliche Weiterleitungen

Skripte, die je nach übergebenem Parameter zu anderen lokalen Adressen weiterleiten, können beispielsweise für Phishing-Angriffe ausgenutzt werden. Das Verfahren wird oft verwendet, um nach der erfolgreichen Anmeldung auf einer Login-Seite direkt zu einer anderen lokalen Seite zu springen. Dabei ist das Ziel Bestandteil des URL, zum Beispiel:

https://login.sichere-seite.example/Pfad/login.cgi?Ziel=
 http%3a%2f%2fwww%2esichere-seite%2eexample%2fziel.html

Nach der erfolgreichen Anmeldung wird der Benutzer auf die Seite

http://www.sichere-seite.example/ziel.html

weitergeleitet. Wird der Parameter für das Ziel nicht ausreichend geprüft, kann eine Seite auf dem Webserver des Angreifers als Ziel angegeben und der Benutzer getäuscht werden. Dabei werden beim Aufruf der eingeschleusten Seite auch alle Parameter, die vom Skript login.cgi weitergegeben werden, an den Server des Angreifers übermittelt. Die einfachste Methode zur Verhinderung derartiger Angriffe besteht darin, wirklich nur zu lokalen Seiten weiterzuleiten. Die Angabe von Protokoll und Server ist dann überflüssig, da sich das Protokoll aus dem Kontext ergibt und als Server sowieso nur der lokale zulässig ist.

Mit dieser bei weitem nicht vollständigen Aufzählung möglicher Schwachstellen wird der Themenkomplex "Sichere Webanwendungen" vorerst abgeschlossen. Ab About Security #127 geht es erneut um die Sicherheit von Webanwendungen. In der nächsten Folge lernen Sie einige Gefahren für Webserver kennen.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver