Java-Konfiguration: So vermeiden Sie Sicherheitsfehlkonfigurationen

Java-Konfigurationen sind allgegenwärtig. Angesichts der vielen Anwendungsframeworks im Java-Ökosystem wird eine korrekte Konfiguration leicht übersehen. Doch eine falsche Java-Konfiguration kann auch zu einem Sicherheitsproblem führen. Wir sprechen dann von einer Fehlkonfiguration. Fehlkonfigurationen gehören zu den berüchtigten OWASP Top 10 und belegen dort einen prominenten sechsten Platz.

Eine falsche Konfiguration Ihrer Java-Anwendung kann zu Sicherheitsproblemen führen. Standardwerte sind zunächst praktisch, weil sie eine Bibliothek oder ein Framework sofort einsatzbereit machen. Doch diese Voreinstellungen sind nicht immer die sicherste Java-Konfiguration: Sie können Informationen preisgeben, die beim Debuggen hilfreich sind, aber auch für Angreifer interessant sein können.

Probleme mit der Java-Konfiguration

Eines der bekanntesten Beispiele ist die Fehlkonfiguration von XML-Parsern in Java. Im

Spickzettel zu 10 Best Practices für Java-Sicherheit haben wir bereits die Möglichkeit von XXE-Angriffen aufgrund einer Fehlkonfiguration besprochen. In diesem YouTube-Video habe ich außerdem erklärt, dass die Standardkonfiguration aller Java-XML-Parser anfällig ist. Wenn Sie einfach die richtige Konfiguration festlegen und externe Entitäten deaktivieren, verhindern Sie mögliche XXE-Angriffe.

Ein weiteres Beispiel ist die richtige Java-Konfiguration für die Fehlerbehandlung. Egal, wie gut Ihre Java-Webanwendung geschrieben ist: Irgendwann tritt zwangsläufig eine Exception auf. Wird eine Exception nicht abgefangen – und somit beispielsweise in einer JSP-Anwendung nicht behandelt –, zeigt das Standardverhalten die Exception und den Stacktrace im Browser an.

Dadurch wird nicht nur sichtbar, dass Sie Java verwenden, sondern auch, welche internen Pakete zum Einsatz kommen. In vielen Fällen enthalten diese Exceptions außerdem konkrete Angaben wie IDs. Keine dieser Informationen ist für Nutzer hilfreich; vielmehr beeinträchtigen sie sogar das Nutzungserlebnis. Noch wichtiger: So werden Informationen offengelegt, die für Personen mit weniger guten Absichten bei der Nutzung Ihrer Anwendung wertvoll sein könnten.

Wenn Sie Fehlerseiten konfigurieren, wie unten gezeigt, leiten Sie Nutzer anhand eines Rückgabecodes oder Exception-Typs weiter, ohne interne Informationen anzuzeigen.

1<error-page>
2   <error-code>401</error-code>
3   <location>/ErrorPage401.jsp</location>
4</error-page>
5
6<error-page>
7   <exception-type>java.lang.Throwable</exception-type>
8   <location>/ErrorPage.jsp</location>
9</error-page>

Konfigurationsprobleme in Java-Bibliotheken und -Frameworks

Java-Bibliotheken und Drittanbieterpakete zu nutzen, um sich einen Teil der Arbeit abzunehmen, ist ein guter Ansatz. Sie sollten sich jedoch bewusst sein, dass die richtige Konfiguration dieser Tools für Ihre Sicherheitsstrategie entscheidend ist. Zum Glück achten die meisten Bibliotheksbetreuer darauf, dass die Standardwerte sicher sind. Änderungen daran mögen zwar praktisch erscheinen, können Sie aber in große Schwierigkeiten bringen.

Nehmen wir zum Beispiel Jackson, eine bekannte Bibliothek, die häufig zum Parsen von JSON in POJOs und umgekehrt verwendet wird. Wenn Sie die Jackson-Bibliothek falsch konfigurieren und „default typing“ zulassen, können beliebige Objekte des Classpaths deserialisiert werden. Das kann zu ähnlichen Deserialisierungs-Schwachstellen führen wie bei der nativen Java-Serialisierung.

Glücklicherweise ist diese Funktion standardmäßig deaktiviert. Dadurch ist es deutlich unwahrscheinlicher, dass beispielsweise eine Deserialisierungs-Schwachstelle mit Codeausführung auftritt. Ändern Sie diese Konfiguration jedoch in Ihrer Java-Anwendung und aktivieren die Funktion, können dadurch unerwünschte Sicherheitsrisiken entstehen. 

Konfigurationsprobleme bei Spring

Das Spring Framework ist das beliebteste Framework für die Anwendungsentwicklung mit Java. Die wichtigsten Funktionen des Spring Frameworks sind Dependency Injection und Inversion of Control.

Spring Boot ist im Grunde eine Erweiterung des Spring Frameworks. Damit können Sie eigenständige Anwendungen mit minimalem oder ganz ohne Konfigurationsaufwand erstellen. Spring Boot bietet eine Reihe von Starter-Komponenten, die Funktionen einfach durch den Import der passenden Abhängigkeit hinzufügen.

Spring Boot Actuator

Wenn Sie die Abhängigkeit spring-boot-starter-actuator zu Ihrem Manifest hinzufügen, stellt Spring Boot Actuator eine Reihe von Endpunkten bereit, die für Betreiber und Entwickler interessant sind.

Denken Sie etwa an den env-Endpunkt, der Umgebungsinformationen anzeigt, zum Beispiel den Classpath, die Beans (alle Spring-Beans in der Anwendung), den threaddump, und den shutdown-Endpunkt. Die vollständige Liste finden Sie in der Dokumentation.

Standardmäßig sind all diese Endpunkte aktiviert, werden zum Glück aber nicht alle per HTTP bereitgestellt. Dennoch lassen sich diese Standardendpunkte leicht konfigurieren und für das Web oder JMX aktivieren. Ebenso einfach lassen sie sich beim Übergang in die Produktionsumgebung wieder deaktivieren. Mit der folgenden Zeile in Ihren Eigenschaften werden alle Endpunkte außer dem Shutdown-Endpunkt über das Web bereitgestellt:

1management.endpoints.web.exposure.include=*

Achten Sie darauf, in der Produktionsumgebung nur die Endpunkte zu aktivieren und bereitzustellen, die Sie tatsächlich benötigen. Am besten blockieren Sie zunächst alle und geben nur einige wenige frei – nicht umgekehrt.

1management.endpoints.enabled-by-default=false
2management.endpoint.info.enabled=true
3management.endpoints.jmx.exposure.include=health,info
4management.endpoints.web.exposure.include=env,beans

Stellen Sie außerdem sicher, dass nur autorisierte Systeme und Personen auf die Endpunkte zugreifen können. Binden Sie dazu Spring Security korrekt ein und konfigurieren Sie es entsprechend.

Spring Boot Developer Tools

Wie der Name schon sagt, handelt es sich bei dieser Spring-Boot-Komponente um eine zusätzliche Sammlung von Tools, die während der Entwicklung hilfreich ist und die Arbeit an Anwendungen erleichtert. Funktionen wie automatische Neustarts, Remote-Debugging und Remote-Updates sind bei der Entwicklung äußerst nützlich.

Laut der Spring-Dokumentation gilt standardmäßig folgendes Verhalten: „Developer Tools werden automatisch deaktiviert, wenn eine vollständig paketierte Anwendung ausgeführt wird. Wird Ihre Anwendung mit java -jar gestartet oder von einem speziellen Classloader geladen, gilt sie als ‚Produktionsanwendung‘.“

Mit der Eigenschaft `spring.devtools.restart.enabled` können Sie dieses sichere Standardverhalten jedoch überschreiben.

Fazit

Generell sollten Sie sich bewusst sein, dass die Konfiguration Ihrer Java-Anwendung genauso wichtig ist wie der Code selbst. Wenn Sie Frameworks und Bibliotheken verwenden, sollten Sie die Standardeinstellungen kennen und wissen, ob bestimmte Änderungen Auswirkungen auf die Sicherheit haben.

Wenn Sie zu viele Informationen preisgeben, etwa durch aktiviertes Debug-Logging oder Endpunkte und Funktionen, die für die Entwicklung vorgesehen sind, kann das Ihrer Anwendung und Ihrem Unternehmen schaden.

Das gilt sowohl für Anwendungsframeworks und Bibliotheken als auch für die Einstellungen Ihres Webservers. Bedenken Sie: Die Offenlegung von Informationen mag auf den ersten Blick harmlos erscheinen. Fügt ein Angreifer jedoch all diese Informationsschnipsel zusammen, erhält er möglicherweise genug Anhaltspunkte für böswillige Handlungen.

Bibliotheken, Frameworks und sogar Anwendungsserver sind sehr nützlich, doch Sie sollten wissen, wie sie funktionieren. Java-Konfiguration und Fehlkonfiguration sind ein ernstes Thema. Achten Sie darauf, nicht versehentlich den Zugriff auf Ihre Anwendung zu ermöglichen, weil Sie vergessen haben, eine bestimmte Eigenschaft in der Konfiguration festzulegen.