Wenn man eine Webanwendung nach Sicherheits-Schwachstellen untersuchen will, dann bietet sich neben der dynamischen Analyse – Pentesten – vor allem die statische Codeanalyse an. Doch was steckt hinter den beiden Ansätzen und worin unterscheiden sie sich?
Pentesten ist eine Black-Box Analyse, bei der man die Interna der Anwendung nicht kennt. Man greift die Anwendung so an, wie es ein Angreifer auch tun würde tut. Auch wenn diese Methodik seine Berechtigung hat und wichtiger Bestandteil der Sicherheitsanalyse ist, gegenüber der statischen Codeanalyse hat sie einige Nachteile, denn viele Schwachstellen sind nicht so einfach zu erkennen. Oft ist es sogar Glücksache bzw. eine Frage des Geschicks des Pentesters, ob gut versteckte Schwachstellen in all ihren speziellen Bedingungen auch gefunden werden.
Bei der statischen Codeanalyse benötigt man den Quellcode der Anwendung. Es kann auch reichen, die Binaries der Anwendung zu haben und diese zu dekompilieren. Der Quellcode der Anwendung wird dann gezielt nach Schwachstellen untersucht, und zwar zunächst an den Stellen, wo sie üblicherweise auftreten: bei der Authentizitierung, dem Berechtigugsmanagement, und den nach außen exponierten Schnittstellen.
Die statische Codeanalyse ist also eine White-Box Analyse, bei der man sich die Logik des Programms anschauen kann. Dort gefundene Schwachstellen könnten dann in Kombination mit den Pentests viel effektiver gefunden werden. Ich empfehle sogar, beide Techniken zu kombinieren, aus mehreren Gründen:
- Beweisführung
- Beweisen der Gültigkeit des Findings
- False Positives werden dadurch aussortiert (fälschlich gefundene Schwachstellen)
- Nachvollziehbarkeit
- Das Dev-Team kann dadurch besser nachvollziehen, dass diese Codestelle eine Schwachstelle ist
- Die Wirksamkeit von Patches vom Dev-Team kann dadurch bewiesen werden
Tools
FindSecBugs
Es gibt verschiedene Tools für die statische Codeanalyse. Am einfachsten sind Pattern-basierte Tools wie FindSecBugs – einem Plugin für das weit verbreitete SpotBugs. Die Ergebnisse sind ganz ordentlich.
Xanitizer
Weit mehr Abdeckung kann man mit einer gezielteren Datenflußanalyse erreichen, wie es mit Xanitizer möglich ist. Man hat damit mehr Aufwand, als nur einen Scanner über den Code laufen zu lassen, aber auch bessere Resultate. Die Idee dahinter ist, dass sämtliche Benutzereingaben simuliert und durch den Code verfolgt werden. Benutzereingaben müssen generell als Gefahrenpotential, als böse eingestuft werden. Werden diese nicht gefiltert und damit neutralisiert, dann muss davon ausgegangen werden, dass dies ein Einfallstor für Angriffsvektoren ist.
Die verschiedenen Stationen, die die Benutzereingaben, in der Anwendung durchlaufen, werden von Xanitizer in 3 Kategorien eingeteilt:
Als Source wird die Station bezeichnet, wo Daten von außen ins System eindringen. Also Schnittstellen aller Art, sowohl von der Benutzerschnittstelle her, als auch technische Schnittstellen, beispielsweise bei einem Web-Service. Daten die hier ankommen, werden als tainted bezeichnet, also als schmutzig, die noch „gewaschen“ werden müssen.
Sinks sind die Datensenken, wohin die Daten letztendlich wandern. Wenn die Daten immer noch tainted sind, wenn sie bei den Sinks ankommen, dann ist dies ein Finding und wird im Report als Schwachstelle angezeigt.
Damit die Daten „gewaschen“ werden, braucht es die genannten Filter, die Sanitizer, die die potenziell schadhaften Daten neutralisieren. Angriffsvektoren die solche Schwachstellen ausnutzen, werden von den Sanitizern sozusagen außer Gefecht gesetzt.
Von Haus aus erkennt Xanitizer bereits viele dieser Elemente im Quellcode vollautomatisch, allerdings muss meist auch noch nachjustiert werden, damit insbesondere Sourcen erkannt werden. Sie sind die wichtigsten Elemente bei der Datenflußanalyse, da sie die Eintrittspunkte ins System repräsentieren.
Insgesamt wird eine gute Analyse durch Xanitizer ermöglicht, die allerdings einiges an Aufwand mit sich bringt. Belohnt wird man aber durch brauchbare Ergebnisse und das gute Gefühl, die Sicherheit in seiner Anwendung deutlich zu verbessern.
Wie man genau mit Xanitizer arbeitet und ihn in den Software-Development-Life-Cycle (SDLC) einbindet und so automatisiert und regelmäßig Sicherheitsanalysen durchführen kann, werde ich in weiteren Blogbeiträgen zeigen.
