Sichere Java-Webanwendungen, Teil 3: Fremdanbieter-Bibliotheken

Umgang mit Bibliotheken

Sicherheitslücken in verbreiteten Bibliotheken werden viel schneller bekannt, als das bei Sicherheitslücken in Individualsoftware jemals sein könnte. Bei einer Lücke im Spring Framework beispielsweise muss ein Angreifer nur noch herausfinden, ob ein Unternehmen eine entsprechende Webanwendung einsetzt. Dazu probiert er den dokumentierten Angriff einfach aus und hat unter Umständen Erfolg: Die Webanwendung ist verwundbar.

Der Testaufwand für einen Angreifer ist somit deutlich geringer als bei einem normalen Angriff. Die Sicherheitslücke in einer Bibliothek ist meist öffentlich dokumentiert, häufig begleitet von einem Codebeispiel zur Nachvollziehbarkeit. Von hier bis zum Angriff ist es dann nur noch ein kurzer Weg. Das soll keinesfalls bedeuten, dass in Bibliotheken gefundene Sicherheitslücken geheim gehalten werden sollen. Java-Entwickler haben stattdessen die Aufgabe, bekannt gewordene Sicherheitslücken vor allem in nach außen exponierten Bibliotheken schnellstmöglich zu beheben und sie zu aktualisieren.

Durch die gerade im Java-Umfeld verbreitete Nutzung von Bibliotheken wird die zeitnahe Aktualisierung zu einer umfangreichen und ständig wiederkehrenden Aufgabe. Immerhin lässt sich die aufwendige Suche nach der aktuellsten Version und den darin gestopften Sicherheitslöchern mit dem OWASP Dependency Check deutlich erleichtern. Im Vergleich zum

mvn versions:display-dependency-updates

liegt der Fokus dabei nicht auf allen verfügbaren Aktualisierungen, sondern er wird auf Sicherheitsprobleme und die dazugehörigen Patch-Releases eingeschränkt. Das relativ neue Kommandozeilen-Tool OWASP Dependency Check ist für Linux, Mac OS X und Windows verfügbar und prüft die in einem Projekt eingesetzten Bibliotheken gegen die National Vulnerability Database (NVD).

Jeder Entwickler kann den Dependency Check lokal per Kommandozeile starten. Sofern kein WEB-INF/lib- oder andere lib-Verzeichnisse mit allen im Projekt verwendeten Bibliotheken vorhanden sind, lässt sich das per Maven Dependencies erledigen:

mvn dependency:copy-dependencies

Im zweiten Schritt wird das in diesem Fall vom Build-Management-Tool Maven explizit generierte Verzeichnis target/dependency an den Dependency Check übergeben:

dependency-check.sh -a MyApplication -s target/dependency

Der Parameter a legt den Namen der überprüften Anwendung fest und kann frei gewählt werden. Der Parameter s enthält den Pfad des zu überprüfenden Verzeichnisses und kann bei mehreren Verzeichnissen mehrfach auftreten. Das Tool stellt noch einige weitere Parameter zur Verfügung, die sich mit

dependency-check.sh --help

anzeigen lassen.

Der erste Aufruf des Tools erfordert die Übertragung von derzeit circa 250 MByte der NVD und benötigt daher einige Minuten. (Regelmäßige) Folgeaufrufe arbeiten deutlich schneller.

Nach Abschluss der Überprüfung wird ein HTML-Report generiert, der die gefundenen Sicherheitsprobleme detailliert auflistet (s. Abb. 1):

Dependency-Check-Report generiert durch den Aufruf auf der Kommandozeile (Abb. 1).

Nicht alle im Report aufgeführten Punkte müssen zum Problem in der eigenen Webanwendung werden. Gleichzeitig muss die Auflistung nicht vollständig sein. Der NVD unbekannte Sicherheitslücken lassen sich selbstverständlich durch den Scan nicht ermitteln.

Alternativ kann man den Dependency Check als Maven-Plug-in integrieren und damit per Maven-Kommando aufrufen. Die Angabe des oder der Bibliotheksverzeichnisse entfällt damit:

<project>
<!-- ... -->
<build>
<plugins>
<!-- ... -->
<plugin>
<groupId>org.owasp</groupId>
<artifactId>
dependency-check-maven
</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

Auch hier stehen weitere Konfigurationsparameter zur Verfügung, die auf der zugehörigen Webseite beschrieben werden.

Der Dependency Check wird anschließend per Maven-Kommando aufgerufen:

mvn org.owasp:dependency-check-maven:check