17.06.2020 | Sebastian Schwegler | comment icon 0 Comment

Statische Codeanalyse: Xanitizer und RIPS im Vergleich

SAST, was für static application security testing steht, ist eine Phase im Software Development Lifecycle (SDL). Ziel dieser Phase ist es, frühzeitig Sicherheitslücken in Softwarecode zu erkennen, sodass diese gar nicht erst in nachgelagerte Systeme gelangen. Neben der statischen Analyse wird auch noch die dynamische Analyse praktiziert, diese setzt jedoch ein lauffähiges Programm voraus.

SAST ist im Security-Kontext den Whitebox-Tests zuzuordnen, da der Quellcode zwingend benötigt wird. Dafür wird beim Whitebox-Test allerdings kein laufendes Programm benötigt. Im Gegensatz hierzu setzt die dynamische Analyse (dynamic application security testing) ein laufendes Programm voraus, benötigt dafür aber keinen Quellcode.

Statische Codeanalyse lässt sich in verschiedenen Detailstufen durchführen, von einfachen Mustererkennungen (wie zum Beispiel SpotBugs) bis hin zur detaillierten Datenflussanalyse

Um statische Codeanalyse durchführen zu können, muss das eingesetzte Programm den Quellcode auf verschiedene Probleme prüfen. Hierfür haben sich verschiedene Techniken wie die Datenflussanalyse in Kombination mit der Taint-Analyse etabliert. Dort wird die Aufrufhierarchie des Quellcodes analysiert und mit einer weiteren Information angereichert: An welchem Punkt gelangen möglicherweise kritische Eingaben in eine Anwendung und wie werden diese Eingaben weiterverarbeitet.

Somit ergibt sich für die statische Codeanalyse der Vorteil (im Vergleich zur dynamischen Analyse), dass das Verfahren schnell, einfach und automatisiert durchführbar ist. So ist SAST ideal für tägliche Tests, zum Beispiel während eines nightly builds, geeignet.

Allerdings sollten bei der Auswahl eines SAST-Tools einige Punkte beachtet werden:

– Das Tool muss die zu untersuchende Sprache unterstützen.
– Welche Arten von Schwachstellen kann das Tool erkennen und welche Arten von Schwachstellen sind im Projekt besonders wichtig?
– Muss der Quellcode in kompilierter Form vorliegen oder kann das Tool auch nur mit reinen .java-Dateien arbeiten?
– Kann das Tool in IDEs integriert werden?
– Lizenzkosten: Freeware, per-User usw.

Bewertungskriterien

Zwei der bekanntesten Tools für statische Codeanalyse sind Xanitizer und RIPS. Um eine möglichst realitätsnahe Bewertung der Tools vornehmen zu können, sollen verschiedene Problemstellungen aus der Praxis analysiert werden. Dazu zählen konkret SQL-Injection, Cross-Site-Scripting und NoSQL-Injection. Alle drei Problemstellungen werden in verschiedenen „Schwierigkeitsgraden“ ausgeführt. So werden SQL-Injections als einfache Query mit Stringkonkatenation von Nutzereingaben, als PreparedStatement mit Stringkokatenation von Nutzereingaben sowie als korrektes PreparedStatement getestet werden. Zudem wird getestet, wie gut die Software-Tools selbst geschriebene Sanitizer bewerten können. Hierzu wird ein eigens entwickelter Sanitizer (welcher nicht alle schädlichen Zeichen korrekt entfernt) eingesetzt. Die Software sollte erkennen, dass hier keine korrekte Bereinigung durchgeführt wird.

Für Cross-Site-Scripting soll sowohl persistentes als auch reflektiertes Cross-Site-Scripting getestet werden. Es sollen Nutzerkommentare in eine Datenbank gespeichert werden. Auch hier soll zusätzlich ein unvollständiger Sanitizer zum Einsatz kommen.

Ergebnisse

Sowohl Xanitizer als auch RIPS haben alle eingebauten Schwachstellen korrekt erkannt. Unvollständige Sanitizer haben beide Tools nicht erkannt, da sie aber die betreffenden Methodenaufrufe als Schwachstelle erkannt haben, fällt dies nicht sonderlich schwer ins Gewicht. Auch das reflektierte Cross-Site-Scripting haben beide Tools erkannt. Somit haben beide Tools alle Schwachstellen zuverlässig erkannt und dabei keine false-positives erzeugt. Auch bei der Analyse von echten Projekten erzeugen beide Tools erstaunlich wenige false-positives; false-negatives konnten bisher nicht festgestellt werden

Analysierbare Sprachen in Xanitizer und RIPS

Während Xanitizer aktuell nur Java analysieren kann, bietet RIPS zusätzlich die Möglichkeit, PHP zu analysieren. Bei PHP wird eine große Anzahl Frameworks untersützt, sodass auch Erweiterungen für CMS problemlos und zuverlässig analysiert werden können.

Xanitizer bereitet aktuell eine Unterstützung für Javascript vor, ebenso RIPS.

Einrichtung und Nutzung von Xanitizer und RIPS

Um Xanitizer beziehungsweise RIPS optimal nutzen zu können, können diverse Einstellungen vorgenommen werden. Die Installation der beiden Tools ist sehr einfach. Während Xanitizer als Programm gestartet wird, liefert RIPS ein Installationsskript, das alle Docker-Container von RIPS herunterlädt und entsprechend einrichtet. Auch weitere Anpassungen wie URLs, Ports und Benutzer können später über dieses Installer-Skript einfach und unkompliziert vorgenommen werden.

SAST mit Xanitizer

Xanitizer erzeugt zu jedem Projekt einen sogenannten Workspace, in welchem alle relevanten Konfigurationen vorgenommen werden können.

Hierzu zählen unter anderem die Einstiegspunkte in die Applikation, die zu berücksichtigenden Klassen sowie die zu analysierenden Sicherheitsprobleme. Hierbei sollte erwähnt werden, dass Xanitizer ausschließlich mit class-Dateien arbeitet, java-Dateien werden nur für die Quellcodedarstellung der Resultate benötigt. Daher ist für Xanitizer zwingend ein kompilierfähiges Projekt notwendig, es sei denn, das Projekt liegt als fertige JAR/WAR-Datei vor.

Sollte Xanitizer nicht alle Klassen in den Workspace aufgenommen haben, können die entsprechenden include patterns im Workspace ergänzt werden. Weiterhin können nicht benötigte Klassen, wie zum Beispiel Unit-Tests, entfernt werden.

Anschließend kann der Call-Graph berechnet werden. Falls in diesem Schritt nicht alle Einstiegspunkt in die Anwendung gefunden wurden, können diese über konfigurierbare Patterns in den Einstellungen des Workspaces nachgetragen werden. Es können viele Parameter definiert und etwa Methodennamen, Parameter, Rückgabewert oder Annotations konfiguriert werden. Anschließend kann die Analyse der Sicherheitslücken beginnen. Hierfür transformiert Xanitizer den Quellcode zunächst in eine von Xanitizer entwickelte Zwischensprache, um die Analyse zu vereinfachen und später neue Sprachen einfacher integrieren zu können. Nach diesem Schritt meldet Xanitizer, welche Sicherheitslücken gefunden wurden. Hier können nun eigene Sanitizer oder false positives markiert werden, sodass diese bei der nächsten Analyse nicht mehr beachtet werden. Findings können kategorisiert und mit Kommentaren versehen werden, sodass auch mehrere Personen an einem Projekt arbeiten können.

Für automatisierte Workflows steht ein Headless-Mode zur Verfügung. In diesem läuft Xanitizer ohne GUI, benötigt aber einen korrekt konfigurierten Workspace. So kann Xanitizer regelmäßig ausgeführt werden, zum Beispiel während Nightly-Builds oder in CI/CD-Pipelines auf einem Buildserver.

Statische Codeanalyse mit Xanitizer

SAST mit RIPS

Ein weiteres SAST-Tool, welches ähnlich arbeitet wie Xanitizer, ist RIPS. RIPS verfolgt einen anderen Architekturansatz und ist als klassische Client-Server-Architektur aufgebaut: Um Quellcode zu analysieren, verbindet man sich per Browser mit der Web-GUI von RIPS und meldet sich mit seinen Zugangsdaten an.

Anschließend kann ein ZIP-Archiv hochgeladen werden. Im Gegensatz zu Xanitizer benötigt RIPS keine class-Dateien, der normale Quellcode aus der Versionskontrolle reicht somit aus.

Anschließend kann ein Analyseprofil definiert werden, in welchem zu prüfende Sicherheitslücken eingestellt werden können.

Auch in RIPS können eigene Sanitizer, Sources und false positives markiert werden. Anschließend analysiert RIPS das Projekt und zeigt die Ergebnisse nach Kategorien sortiert an. Im Gegensatz zu Xanitizer wird bei RIPS der Quellcode nicht transformiert, es kommt für jede Sprache eine eigens entwickelte Analyse-Engine zum Einsatz. Auch in RIPS können Findings markiert und kommentiert werden.

Statische Codeanalyse mit RIPS

Integration in den SDLC

Sowohl RIPS als auch Xanitizer lassen sich hervorragend in bestehende SDLC eingliedern. So können sie als Jenkins-Plugin oder GitLab-Pipeline eingebunden werden. RIPS bietet zusätzlich noch Plugins für Eclipse und IntelliJ an, sodass Entwickler noch vor einem Commit lokal eine Prüfung durchführen können. Auch können beide Tools als Maven-Goal eingebunden werden. RIPS unterstützt zusätzlich noch Gradle, während Xanitizer noch ANT unterstützt.

Allerdings müssen beide Tools für einen sinnvollen Einsatz im SDLC entsprechend konfiguriert werden, was zumindest anfänglich etwas Zeit in Anspruch nimmt.

RIPS und Xanitizer im Vergleich

Die nachfolgende Tabelle fasst die bereits in den vorausgegangenen Ausführungen erläuterten Unterschiede zwischen RIPS und Xanitizer noch einmal zusammen:

AspektRIPSXanitizer
ArchitekturClient-Server-ArchitekturEinzelanwendung mit optionalem Headless-Mode
NutzerverwaltungVerschiedene NutzeraccountsKeine Nutzerverwaltung
AnalyseEine Analyse-Engine pro SpracheTransformation in Zwischensprache
Integration in CI/CDJenkins, SonarQube, Gitlab, Bitbucket, Bamboo, Drone, TeamCity, CircleCI, TravisCIJenkins, SonarQube, DefectDojo, Jackhammer, Command Line
Integration in BuildMaven, GradleMaven, Ant
Unterstützte SprachenJava, PHPJava, Javascript (ab Version 5.0)
LizenzmodelleEinzelnutzer, Mehrbenutzer, Mehrbenutzer mit mehreren AnwendungenTages-, Wochen-, Jahreslizenz mit Abstufungen in Maschinen-, Floating- und Firmenweite Lizenz
LizenzkostenAuf Anfrage400 EUR (Tageslizenz) bis 14.000 EUR (Floating-Jahreslizenz), Firmenlizenz auf Anfrage

Fazit

Statische Codeanalyse eignet sich hervorragend, um bereits in der Entwicklungsphase einer Software mögliche Schwachstellen zu erkennen und noch vor einer Auslieferung in die Produktivumgebung zu beheben. Hier unterstützt RIPS besonders mit einem Plugin für gängige IDEs. Sowohl RIPS als auch Xanitizer bieten eine gute Integration in die Versionsverwaltung. Das Markieren von false-positives funktioniert bei beiden Tools einwandfrei und beide Tools können diese Markierungen auch beim Zusammenführen von Branches der Versionskontrolle beibehalten.

Allerdings hat SAST einen entscheidenden Nachteil: Der Code wird nicht ausgeführt, sodass anhand verschiedener Heuristiken entschieden werden muss, ob eine potentielle Sicherheitslücke vorliegt, oder nicht. Dadurch kann vor allem in der Einführungsphase eines solchen Tools ein erhöhter Aufwand entstehen, da möglicherweise etliche false-positives markiert werden müssen. Dieser Aufwand sollte auf jeden Fall erbracht werden, da nur so eine sinnvolle Nutzung von SAST möglich ist, denn: Wenn ein Softwareentwickler ein Security-Tool als lästig empfindet, wird er es nicht benutzen oder die vielen Findings nicht beachten.

Weiterhin stellen Bibliotheken und Frameworks eine Hürde für SAST-Tools dar, da sich hier häufig Aufrufhierarchien ändern oder der Quellcode teilweise gar nicht vorliegt (meist bei selbst entwickelten Frameworks) und somit keine verlässliche Aussage getroffen werden kann, ob hier sicherheitsrelevante Methoden oder ähnliches aufgerufen werden.

Daher sollte SAST immer mit einer dynamischen Analyse kombiniert werden, um möglichst viele Schwachstellen einer Anwendung erkennen zu können.

rips sast xanitizer

Leave a Comment