Skip to main content


Grundregeln zum Entwickeln von sicheren Anwendungen (Teil 2)

Die zwei wichtigsten Grundregeln haben Sie ja bereits kennen gerlernt: "Akzeptieren Sie ihre Verantwortung" und "Trauen Sie keinen Daten". Darauf aufbauend folgen in dieser Folge unserer Artikelserie noch einige weitere Regeln, um die zwei bereits bekannten ein wenig zu verfeinern.

3. Nutzen Sie Fuzzing

Nutzen Sie Fuzzing zum Testen Ihrer Anwendungen: Dabei werden zufällig erzeugte Daten als Eingabe verwendet, die dann bei der Verarbeitung ggf. vorhandene Fehler auslösen. Die meisten Fehler und sich daraus ergebenden Schwachstellen beim Verarbeiten von Daten werden entweder durch Zufall oder durch Fuzzing gefunden. Gerade bei der Implementierung der Analyse komplexer Daten schleichen sich leicht Fehler ein, die von regulären Daten nie ausgelöst würden. Erst wenn irreguläre Daten verarbeitet werden, macht sich der Fehler bemerkbar. Darum besorgen Sie sich Tools zum Erzeugen der für Ihr Programm passenden Fuzzing-Daten oder schreiben Sie sich ein eigenes – damit füttern Sie Ihr Programm dann mit zufälligen Daten. Je öfter, desto besser, denn je mehr irreguläre Daten verarbeitet werden, desto größer ist die Wahrscheinlichkeit, dass dabei versteckte Fehler auftreten.

4. Verwenden Sie keinen unsicheren Code

Bevor sie neuen Code zu einer Anwendung hinzufügen, prüfen Sie dessen Sicherheit. Quellcode-Analysetools helfen Ihnen bei der Suche nach problematischen Codepassagen. Jedes gefundene Problem muss vor der Verwendung des Codes behoben werden. Zusätzlich können Sie eigene Regeln für unerwünschten Code aufstellen: In C-Code sollte z.B. auf unsichere Funktionen wie strcpy verzichtet werden oder beim Einsatz von Kryptografie auf die Verwendung veralteter Systeme wie DES, MD4 und MD5.

Vorhandener Code, der nicht schon sicher entwickelt wurde, muss ebenfalls auf mögliche Schwachstellen untersucht werden, bevor er weiter verwendet wird. Erst, wenn der Code auf dem gleichen Sicherheitsniveau wie der aktuelle Code ist, sollte er weiter verwendet werden.

Verwenden Sie vorhandenen, sicheren Code mehrfach, statt Funktionen mehrfach neu zu implementieren. Wenn sie z.B. bereits Code zur Analyse eines bestimmten Dateiformats haben, dann machen Sie diesen Code so sicher wie möglich und verwenden ihn immer, wenn eine entsprechende Datei analysiert werden muss, statt jedes Mal das Rad neu zu erfinden.

5. Verwenden Sie Bedrohungsmodelle

Bedrohungsmodelle helfen Ihnen, schon beim Entwurf die möglichen Gefahren durch und für Ihr Programm zu ermitteln und somit mögliche Gegenmaßnahmen zu finden. Bedrohungsmodelle erfassen, woher welche Daten stammen, wie sie verarbeitet werden und wohin sie ggf. gehen. Diese Informationen können Sie auch für die Prüfung des fertigen Codes nutzen: Prüfen Sie für alle Datenpfade, ob die Daten korrekt geprüft und verarbeitet werden und ob alle Fehler korrekt aufgefangen werden.

6. Verwenden Sie die für Ihren Zweck bestmöglichen Tools

Es gibt eine ganze Reihe von Tools, die Sie bei der Entwicklung sicherer Programme unterstützen. Tools zur Quellcodeanalyse, zum Fuzzing, zur Laufzeitanalyse, etc. Suchen Sie sich die für Ihren speziellen Zweck und Ihre persönliche Arbeitsweise besten davon aus und nutzen Sie diese regelmäßig. Prinzipiell erfüllt jedes Tool mehr oder weniger seinen jeweiligen Zweck, aber wenn Sie es nur ungern bedienen oder seine Ausgaben nur mühsam verstehen, werden Sie schnell versucht sein, auf seinen Einsatz zu verzichten.

7. Bleiben Sie auf dem Laufenden

Die IT-Sicherheit ist ein sehr dynamisches Umfeld: Ständig kommen neue Gefahren hinzu, sodass es nicht ausreicht, einmal ein Buch oder ein paar Webseiten zu lesen, um danach alle möglichen Gefahren zu kennen. Damit verschaffen Sie sich nur einen ersten Überblick und eine Grundlage, auf der sie aufbauen können. Dieses Wissen müssen sie aktuell halten, z.B. indem sie entsprechende Blogs oder Mailinglisten verfolgen.

Beispiel I: Binary Planting

Einem Programm mit einem unsicheren Suchpfad für nachzuladende Bibliotheken eine falsche Bibliothek unterzuschieben, ist ein altbekannter Angriff. Lange war man der Ansicht, dass das nur ein lokales Problem sei, sodass maximal ein bösartiger Benutzer sich so höhere Benutzerrechte verschaffen könnte. Erst 2010 fiel auf, dass sich diese Schwachstellen auch aus der Ferne ausnutzen lassen: Die Bibliothek wird ggf. auch von WebDAV- und Netzwerklaufwerken geladen. Dieser " Binary Planting" genannte Angriff ist also nur ein neuer Angriffsvektor für das bekannte " DLL Preloading", das es aber in sich hat – die Liste betroffener Programme wächst laufend.


Dieses Beispiel demonstriert gut die Asymmetrie zwischen Entwicklern und Angreifern: Die Angreifer sind immer im Vorteil, denn Sie als Entwickler müssen während der Entwicklung dafür sorgen, dass Ihr Programm während seiner gesamten Nutzungsdauer sicher ist, während potentielle Angreifer danach alle Zeit der Welt haben, um eine Schwachstelle zu finden und diese auszunutzen. DLL Preloading war als lokale Schwachstelle nur ein Problem, wenn das betroffene Programm höhere Benutzerrechte als der es aufrufende Benutzer hatte. Bei der nun bekannt gewordenen Ausnutzung aus der Ferne stellt aber jedes Programm mit entsprechender Schwachstelle eine Gefahr dar, da ein entfernter Angreifer darüber seinen Code einschleusen kann. Entsprechend müssen nun sehr viele Programme nachgebessert werden, in denen der Fehler bisher nie auffiel – denn wer sucht schon in einer Anwendung, die nur mit den Rechten des jeweiligen Benutzers läuft, nach einer Schwachstelle, die nur in Anwendungen mit höheren Benutzerrechten sinnvoll ausgenutzt werden kann?

Stecken Sie nicht den Kopf in den Sand!

Mit neuen Schwachstellenklassen und Angriffen oder auch "nur" neuen Angriffsvektoren muss man ständig rechnen. Als Entwickler müssen Sie auf solche Vorfälle schnell reagieren und die eigenen Programme darauf prüfen und ggf. nachbessern – bevor Cyberkriminelle die Schwachstelle entdecken und ausnutzen. Nun kann und wird niemand verlangen, dass Sie alle Programme bis in alle Ewigkeit aktualisieren und weiterentwickeln. Aber wenn Sie ein Programm oder auch nur eine Programmversion nicht mehr unterstützen wollen, kündigen Sie das auch so an und lassen Sie es nicht heimlich verschwinden. Es ist nichts Ehrenrühriges daran, eine Anwendung nicht mehr zu unterstützen, weil es z.B. neuere Versionen gibt oder es einfach nicht mehr ins eigene Geschäftsmodell passt. Nicht gut ist es, dies heimlich zu tun, und z.B. beim Auftreten einer Schwachstelle einfach das Programm von der Homepage verschwinden zu lassen und so zu tun, als wäre es nie da gewesen.

Wie schon in der ersten Grundregel festgehalten wurde: Es ist Ihr Programm, Ihr Fehler und damit Ihre Schwachstelle. Wenn Sie diese nicht mehr beheben wollen, Sie die Benutzer darüber informieren. Ein einfacher Hinweis wie "In meinem Programm xyz wurde eine kritische Schwachstelle gefunden. Da ich das Programm nicht mehr weiter entwickele, werde ich diese nicht mehr beheben. Bitte verwenden Sie das Programm nicht mehr!", vielleicht noch verbunden mit einem Verweis auf mögliche Alternativen, schadet Ihnen nicht, aber schützt die Benutzer Ihres Programms vor eventuellem Schaden.

 


 

Autor des Artikels

Dipl.-Inform. Carsten Eilers ( www.ceilers-it.de) ist als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz tätig und als Autor verschiedener Artikel und des Buches "Ajax Security" bekannt.  Seinen Blog finden Sie hier.

 



These postings are provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use. The content of these security articles are the own personal opinions from Carsten Eilers.

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?