Ounce Labs Advanced Research Team (ART) hat auf zwei mögliche Angriffspunkte hingewiesen, die sich durch die Verwendung des Model View Controller (MVC) des Spring-Frameworks ergeben (Whitepaper, Registrierung erforderlich). Werden bei der Verwendung des MVC Sicherheitsgrundsätze nicht berücksichtigt, kann ein Angreifer die Anwendungslogik manipulieren und sensitive Informationen ausspähen. Die neuen Angriffe werden als "Spring MVC Data Submission to Non-Editable Fields" und "Spring MVC ModelView Injection" bezeichnet.
"Spring MVC Data Submission to Non-Editable Fields"
Der "Spring MVC Data Submission to Non-Editable Fields" genannte Angriff ist möglich, wenn Springs DataBinder verwendet wird, um ungeprüfte Request-Daten des Clients an Server-Objekte zu binden. Der verwendete WebDataBinder versucht, alle im Request übergebenen Parameter an entsprechende Objekte auf dem Server zu binden. Werden von der Webanwendung nicht erwartete Parameter übergeben, werden sie trotzdem an vorhandene Objekte gebunden. Je nachdem, um was für Objekte es sich handelt, kann das Auswirkungen auf den Ablauf der Anwendung haben. Vereinfacht ausgedrückt: Wird der DataBinder verwendet, um Daten aus einen Webformular zu übernehmen, können danach alle vorhandenen Felder mit vom Angreifer gelieferten Daten ('tainted data') gefüllt sein, nicht nur die, für die das Formular auf dem Client Eingaben vorsieht. Wird das im weiteren Programmablauf nicht berücksichtig, wird mit manipulierten Daten weitergearbeitet.
Als Beispiel für einen Angriff nennt Ounce Labs die Übernahme eines Benutzerkontos einer Webanwendung. Im Beispiel wird für das Anlegen eines neuen Benutzers und das Ändern der Daten eines vorhandenen Benutzers das gleiche Skript verwendet. Der wesentliche Unterschied besteht dabei nur darin, dass im ersten Fall der Benutzername eingegeben werden kann und im zweiten der vorhandene Benutzername angezeigt wird. Der Angreifer kann das ausnutzen, um beim Ändern seiner eigenen Daten über einen Proxy einen anderen Benutzernamen einzufügen und dadurch die Kontrolle über dieses Konto zu übernehmen.
Die Dokumentation des Spring-Frameworks weist bereits auf die Möglichkeit derartiger Angriffe und die Notwendigkeit einer Prüfung der Daten hin. Ebenso wie beim zweiten vorgestellten Angriff handelt es sich auch nicht um eine Schwachstelle im Framework. Das tut genau das, was es soll: alle übergebenen Parameter auf Objekte verteilen. Die Möglichkeit, falsche von richtigen Werten zu unterscheiden, hat es gar nicht. Das ist die Aufgabe der Webanwendung. Das Whitepaper der Ounce Labs enthält weitere Hinweise, wie die übergebenen Daten geprüft werden können.
"Spring MVC ModelView Injection"
Bei der "Spring MVC ModelView Injection" werden vom Client gelieferte Daten direkt als Name eines zu rendernden Views verwendet. Werden die Namen interner Ressourcen übergeben, können darüber eigentlich unzugängliche Dateien gelesen werden Ein Angreifer kann das ausnutzen, um den gesamten Inhalt des Webroot-Verzeichnisses und seiner Unterverzeichnisse zu lesen. Wie schon beim ersten Angriff gilt: Wer dem Client vertraut, hat auf Sand gebaut. Vom Benutzer gelieferte Daten müssen vor ihrer Verwendung geprüft und dürfen niemals direkt verwendet werden.
Generelles Problem aller Frameworks: Mangelnde Transparenz
Frameworks machen die Entwicklung von Programmen einfacher, da sie die Entwickler von vielen Routineaufgaben entlasten. Dazu stellen sie eine Reihe von Funktionalitäten bereit, über deren eigentliche Umsetzung meist wenig bekannt ist. Das ist ja auch gerade der Zweck eines Frameworks: Bestimmte Funktionalitäten bereitzustellen, ohne dass sich der Entwickler um deren Umsetzung kümmern muss. Wollte er das, könnte er auch auf das Framework verzichten und die benötigten Funktionalitäten selbst implementieren. Die mangelnde Transparenz hat aber auch einen Nachteil: Oft sind nicht alle Auswirkungen der verschiedenen Funktionalitäten bekannt. Mit jeder Abstraktionsschicht verringert sich der Blick auf die eigentliche Implementierung. Manche Nebenwirkungen sind vielleicht nicht einmal den Entwicklern der Frameworks bekannt, andere sind zwar bekannt, ihre Bedeutung wird von den Nutzern der Frameworks aber nicht in vollem Umfang erkannt, siehe oben.
Frameworks ersetzen das Denken nicht
Nur, weil ein Framework verwendet wird, statt Routineaufgaben selbst zu programmieren, heißt das nicht, dass man bei der Entwicklung nun das Denken einstellen kann. Ganz im Gegenteil: Während man sich ohne Framework nur um die Sicherheit des eigenen Codes und der verwendeten Programmiersprache Gedanken machen muss, kommt beim Framework auch dessen Sicherheit dazu. Das bedeutet nicht nur, auf eventuell entdeckte Schwachstellen im verwendeten Framework zu reagieren, sondern auch, das Framework selbst sicher zu verwenden. Der wichtigste Punkt dabei ist, sich über die Wirkung aller verwendeten Funktionalitäten zu informieren und mögliche Nebenwirkungen zu erkennen. Wobei im Fall der von Ounce Labs beschriebenen Probleme die Berücksichtigung des alte Grundsatzes "Traue nie dem Client" ausreicht, um die Angriffe zu verhindern. Werden die Benutzereingaben geprüft, können darüber weder zusätzliche Parameter eingeschleust noch falsche Werte übergeben werden. Aber wer weiß schon, welche Nebenwirkungen dieses oder andere Frameworks noch bereit halten? Darum: Augen auf beim Frameworkeinsatz!
Carsten Eilers
Kommentare