Sichere Java-Webanwendungen, Teil 3: Fremdanbieter-Bibliotheken

Inhaltsverzeichnis

Bei Bibliotheken von Fremdanbietern denken die wenigsten Java-Programmierer an Sicherheitsprobleme. Tatsächlich werden aber veraltete und bekannte verwundbare Bibliotheken zunehmend häufiger bei Angriffen auf Java-Webanwendungen ausgenutzt. Daher ist ein Umdenken gefordert: Regelmäßige Aktualisierungen der eingesetzten Bibliotheken sind ein absolutes Muss.

Die Verwendung von Bibliotheken und Frameworks ist in Java sicherlich weiter verbreitet als in vielen anderen Programmiersprachen. (Im weiteren Verlauf des Artikels wird nicht mehr zwischen einfachen Bibliotheken und umfangreichen Frameworks unterschieden: "Ein JAR ist ein JAR.") Es ist zweifellos der richtige Ansatz, häufig benötigte Features oder komplexe Operationen auszulagern und mit umfassend getesteten, gepflegten und oft weit verbreiteten Bibliotheken zu erledigen.

Mehr Infos

Sichere Java-Webanwendungen

• Teil 1: Cross-Site Scripting
• Teil 2: Cross-Site Request
• Teil 3: Fremdanbieter-Bibliotheken

Ganz sorglos sollte man allerdings auch hier nicht programmieren und beim Einsatz einer Bibliothek keinesfalls denken, dass sich irgendein anderer Entwickler schon vollständig um die Sicherheit gekümmert hat. Der in den OWASP Top 10 2013 neu hinzugekommene Punkt "Using Known Vulnerable Components" und auch die länger bekannte "Security Misconfiguration" zeigen, dass sich dieser Umstand vor allem im Java-Umfeld weiter zu verbreiten droht.

Aus Entwicklung wird Konfiguration

Beim Einsatz umfangreicher Frameworks oder Bibliotheken müssen sich Entwickler stets bewusst machen, dass sie weiterhin die Verantwortung für die korrekte und sichere Konfiguration und Verwendung haben. Dabei spielt es keine Rolle, ob man ein umfangreiches Security-Framework oder eine kleine spezialisierte Utility-Bibliothek einsetzt. Was zuvor häufig in jeder Anwendung erneut selbst entwickelt wurde, wird jetzt in einer 3rd-Party-Bibliothek aufgerufen. Für die Umsetzung mancher Anforderungen ist dazu nur noch Konfiguration und keinerlei Programmierung mehr notwendig. Zumindest aber hat sich der Programmieraufwand im Vergleich zur Eigenentwicklung (deutlich) reduziert.

In jedem Fall haben Entwickler die Aufgabe, die Konfiguration korrekt durchzuführen und vor allem die dabei verwendete 3rd-Party-Funktion zu testen. Jede externe Bibliothek wird zum Bestandteil der eigenen Anwendung. Bei einer Eigenentwicklung wird jede Funktionalität mit Unit- und Integrationstests abgesichert; für fremde Bibliotheken – vor allem für solche mit kritischen oder sicherheitsrelevanten Aufgaben – muss dasselbe gelten.

Fehlende Verantwortlichkeiten nach der Integration

Die meisten Java-Projekte starten heute mit dem Erstellen einer Maven-Konfiguration. Einige grundlegende und nahezu immer notwendige Bibliotheken – etwa Apache Commons oder Google Guava – werden häufig automatisch eingetragen. Dazu kommen je nach Java-Anwendung weitere spezielle Bibliotheken wie das Spring Framework. Häufig nutzt man die Gelegenheit beim Projektstart, um auf den Webseiten der Bibliotheken (oder einem öffentlichen Maven Repository) nach den aktuellen Versionen zu suchen, und aktualisiert die Versionsinformationen in der pom.xml.

Im Laufe des Projekts kommen nun immer neue Abhängigkeiten hinzu. Gelegentlich werden auch vorhandene Versionen aktualisiert, etwa wenn ein (Sicherheits-)Patch zur Verfügung gestellt wird und einer der Entwickler (zufällig) davon erfährt. Eine konsequente und zeitnahe Pflege findet aber vor allem bei näherkommendem Release-Datum kaum mehr statt. Schließlich sind aktualisierte Bibliotheken genauso wie Änderungen im eigenen Code umfassend zu testen und haben unter Umständen unerwartete Seiteneffekte auf andere Bibliotheken im Projekt.