10 Best Practices für Maven-Sicherheit

Auch diesen Monat bieten wir Ihnen wieder einen Spickzettel rund um Sicherheit! Wir stellen Ihnen 10 Best Practices vor, mit denen Sie Ihr Maven-Know-how verbessern können. Maven ist das führende Build-Tool im Java- und JVM-Ökosystem. *SPOILER-ALARM!* Die Ergebnisse unserer Umfrage zum JVM-Ökosystem, die im Oktober veröffentlicht werden, zeigen: Mavens Vormachtstellung setzt sich auch 2018 fort. Es sieht nicht danach aus, als würde sich das ändern: Sechs von zehn Entwicklern nutzen das Build-Tool in ihrem Hauptprojekt, wie unten dargestellt.

Dies ist bereits unser fünfter Spickzettel in diesem Jahr (wow, wie die Zeit vergeht!). In den vergangenen Monaten haben wir bereits Spickzettel zu Typinferenz in Java, Best Practices zur GitHub-Sicherheit, Zip Slip und 10 Best Practices für die Sicherheit von Spring Boot erstellt. Dieser Beitrag entstand auf Kreta, als ich mit dem Vorsitzenden des Apache-Maven-Projekts, Robert Scholte, am Strand lag. Wir saßen im herrlichen goldenen Sand, schwammen im wunderschönen, warmen kretischen Meer und kamen auf die folgenden 10 Sicherheitstipps – sagen Sie nicht, wir würden nie etwas für Sie tun!

1. Verschlüsseln Sie Ihre Secrets

Seit Maven 2.1.0 lassen sich Passwörter auf gemeinsam genutzten Build-Computern verschlüsseln. Wenn mehrere Benutzer Zugriff auf einen gemeinsam genutzten Computer haben oder eine settings.xml-Datei für viele Benutzer zugänglich ist, sollten alle darin gespeicherten Secrets verschlüsselt werden. Wenn Sie settings.xml-Dateien mit anderen Entwicklern teilen, sollten Sie die Secrets daraus entfernen, damit nur autorisierte Benutzer Maven-Artefakte in Repositories bereitstellen dürfen – und nicht das gesamte Team. Diese autorisierten Benutzer hätten dann eine settings-security.xml-Datei, die lokal in ihrem Maven-Einstellungsordner oder an einem anderen privaten Speicherort abgelegt ist. Wenn Ihre Builds an einem gemeinsam genutzten Speicherort ausgeführt werden, auf den das gesamte Team zugreift, sollten Sie die Secrets in der settings.xml-Datei verschlüsseln. Dazu müssen Sie ein Master-Passwort erstellen, das Sie sicher speichern und angemessen weitergeben können.

Sie können das Master-Passwort und die Server-Passwörter über die Maven-CLI erstellen, indem Sie den folgenden Befehl ausführen:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password
Master password:
{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}

Speichern Sie das erstellte Passwort wie folgt in Ihrer Datei ~/.m2/settings-security.xml:

<settingsSecurity> <master>{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}</master> </settingsSecurity>

Nun können Sie ein Server-Passwort erstellen, indem Sie den folgenden Befehl ausführen:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-password
Password:
{155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}

Speichern Sie es wie folgt in Ihrer Datei settings.xml:

<server> <id>my.server</id> <username>smaple</username> <password>Simon reset this password on 2019-03-11, expires on 2019-04-11 {155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}</password> </server>

Weitere Informationen finden Sie in der Maven-Dokumentation zum Speichern von Secrets in der Datei settings.xml.

2. Verwenden Sie keine Passwörter in der CLI

Im vorherigen Beispiel haben wir gezeigt, wie Sie Secrets korrekt in Ihre Konfigurationsdateien aufnehmen. Es gibt auch einen falschen Weg – und wir möchten sicherstellen, dass Sie ihn kennen, damit Sie ihn vermeiden können! Eine veraltete Option der oben gezeigten CLI-Befehle ermöglicht es, ein Passwort für beide Verschlüsselungsbefehle in der Befehlszeile anzugeben, zum Beispiel:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password P@ssw0rd

„10 Damit würden zwar verschlüsselte Secrets erstellt, aber Sie sollten Secrets niemals im Klartext in eine Befehlszeile eingeben. Sie werden im Verlauf der Konsole gespeichert und lassen sich leicht wiederherstellen.

3. Verwenden Sie immer HTTPS

Maven-Repositories können lokal oder remote sein. Ihre lokalen Repositories, die sich üblicherweise im Verzeichnis ~/.m2/repository/ Ihres Computers befinden, enthalten zwischengespeicherte Versionen der Projekte, die Sie zuvor heruntergeladen haben. Zu den Remote-Repositories können Maven Central oder ein Repository gehören, das Ihre Organisation mit Artifactory oder einer ähnlichen Lösung eingerichtet hat. Welche Repositories Ihr Build verwendet, sehen Sie im Element Ihrer pom.xml. Wie bei den meisten Kommunikationswegen heutzutage ist es äußerst wichtig, für Verbindungen zu Drittanbieterdiensten HTTPS zu verwenden. Maven-Repositories bilden hier keine Ausnahme. Wenn Sie überprüfen, ob Sie tatsächlich mit den gewünschten Servern kommunizieren, verringern Sie das Risiko von Man-in-the-Middle-Angriffen und insbesondere von Sicherheitslücken durch den Download von Ressourcen über ein unsicheres Protokoll.

Um dies zu vermeiden, kommunizieren Sie mit jedem Repository immer über HTTPS – auch wenn es von Ihrer eigenen Organisation gehostet wird. Stellen Sie dazu sicher, dass Ihre Elemente in der pom.xml https in ihren URLs verwenden.

4. Prüfen Sie den Zustand von Abhängigkeiten

Anwendungen beziehen häufig Abhängigkeiten von Drittanbietern. Entwickler tun dies oft, ohne sich über die Frage „Erfüllt die Abhängigkeit ihren Zweck?“ hinaus viele Gedanken zu machen. Doch ebenso wichtig ist es, den allgemeinen Zustand der Abhängigkeit zu prüfen, bevor Sie sie in Ihre Anwendung aufnehmen. Folgende Kriterien können Ihnen dabei helfen, den Zustand eines Projekts zu beurteilen, von dem Sie abhängig werden möchten:

Anzahl aktiver Committer – Open-Source-Projekte, die nur von einer oder zwei Personen betreut werden, können riskant sein, da sie für Updates und Releases oft von einer einzelnen Person abhängen. Ein Team aus Mitwirkenden reduziert dieses Risiko erheblich.

Dokumentierte Sicherheitsrichtlinien – Wenn Sie Benutzern ein Verfahren zum Melden von Sicherheitsproblemen bereitstellen, steigt die Wahrscheinlichkeit, dass das Projekt überhaupt davon erfährt. Ebenso können Benutzer Abhängigkeiten sicherer nutzen, wenn es einen Mechanismus gibt, über den sie über Sicherheitsprobleme und deren Behebung informiert werden.

Regelmäßige Updates und Releases – Stellen Sie sicher, dass die Projekte, von denen Sie abhängig sind, aktiv weiterentwickelt werden. Das hilft Ihnen zunächst bei der zukünftigen Entwicklung Ihres eigenen Projekts, denn Sie können darauf vertrauen, dass Ihre Abhängigkeiten mit Sprachfunktionen und Ähnlichem auf dem neuesten Stand bleiben. Aus Sicherheitssicht ist es außerdem wichtig, dass gemeldete Sicherheitsprobleme zeitnah behoben werden.

5. Prüfen Sie auf bekannte Sicherheitslücken

Angreifer nehmen Open-Source-Abhängigkeiten immer häufiger ins Visier. Die Wiederverwendung von Bibliotheken bietet böswilligen Hackern viele potenzielle Opfer, wenn sie versuchen, eine bekannte Sicherheitslücke auszunutzen. Deshalb müssen Sie sicherstellen, dass der gesamte Abhängigkeitsbaum Ihrer Anwendung frei von bekannten Sicherheitslücken ist.

Tools wie Snyk melden bekannte Sicherheitslücken in Ihren Maven-Build-Artefakten und kennzeichnen die betroffenen Abhängigkeiten. In einem Dashboard erhalten Sie eine Liste der Sicherheitslücken in den Paketen, die Sie über Ihre pom.xml-Datei einbinden.

Außerdem erhalten Sie Empfehlungen zur Behebung, etwa durch Versionsupgrades oder Patches des Snyk-Sicherheitsteams. Wenn Sie beispielsweise Ihr Quellcodeverwaltungstool wie GitHub, Bitbucket oder GitLab verbinden, können Sie Sicherheitsprobleme automatisch über einen Pull-/Merge-Request beheben. Snyk schützt Ihre Umgebung kontinuierlich: Künftige Pull-/Merge-Requests werden mithilfe von Webhooks automatisch getestet, damit andere Entwickler keine neuen Sicherheitslücken in das Projekt einbringen.

Snyk ist sowohl über eine Web-UI als auch über eine CLI verfügbar. So können Sie es ganz einfach in Ihre CI-Umgebung integrieren und so konfigurieren, dass Ihr Maven-Build abgebrochen wird, wenn Sicherheitslücken den von Ihnen festgelegten Schweregrad überschreiten.

Sie können Snyk kostenlos nutzen, um Open-Source-Projekte oder private Projekte mit einer begrenzten Anzahl von monatlichen Tests zu prüfen.

6. Prüfen Sie Ihre Prüfsummen

Prüfsummen sollen Fehler erkennen, die bei der Datenübertragung oder -speicherung entstehen können. Deshalb sollten Sie die Prüfsummen aller Projektabhängigkeiten überprüfen. Prüfsummen werden häufig verwendet, um die Datenintegrität zu bestätigen. Sie sollten zwar nicht als Nachweis für die Authentizität Ihrer Abhängigkeiten dienen, bieten aber eine zusätzliche Sicherheitsprüfung. Ab Maven 4 werden die Prüfsummen aller Abhängigkeiten standardmäßig geprüft. Bis dahin können Sie mit dem Flag -C Ihre Maven-Befehle so ausführen, dass Prüfsummen geprüft und Builds bei Abweichungen abgebrochen werden.

$ mvn -C install // fail if checksums don’t match

$ mvn -c install // warn if checksums don’t match

7. Verwenden Sie keine Properties für Passwörter

Properties werden in Maven häufig als Platzhalter in pom.xml-Dateien verwendet. Sie können in der Beispieldatei pom.xml unten eine Property festlegen, die wir my.property nennen:

<properties>
  <my.property>value</my.property>
</properties>

Sie können nun überall in dieser pom.xml-Datei mit der Schreibweise ${my.property} auf die Property my.property verweisen. Das ist zwar sehr praktisch, macht es aber auch sehr einfach, Passwörter zur späteren Verwendung zu speichern. Damit speichern wir Passwörter natürlich im Klartext und teilen sie möglicherweise mit dem ganzen Team. Plugins sollten stattdessen Server-Einträge aus Ihrer settings.xml verwenden.

8. Verwenden Sie Maven-Entwickler/Rollen

Wie der Bericht zum Stand der Open-Source-Sicherheit gezeigt hat, ist es wichtig, Menschen die nötigen Informationen bereitzustellen, damit sie eine Sicherheitslücke melden können. GitHub-Repositories mit einem Verfahren zur Offenlegung von Sicherheitslücken erhalten mehr als dreimal so häufig Meldungen zu Sicherheitslücken wie Repositories ohne ein dokumentiertes Offenlegungsverfahren.

In der Maven-Datei pom.xml können Sie ein developers-Tag hinzufügen, das Informationen zu Sicherheitskontakten enthält. So weiß jeder, an wen er sich in Ihrem Team wenden kann, wenn ein Sicherheitsproblem auftritt. Unten sehen Sie ein Beispiel, in dem ich Danny als unseren internen Sicherheitsexperten hinzufüge.

<developers>
    <developer>
      <id>grander</id>
      <name>Danny Grander</name>
      <email>danny@snyk.io</email>
      <organization>Snyk</organization>
      <organizationUrl>https://snyk.io</organizationUrl>
      <roles>
        <role>security</role>
      </roles>
    </developer>
  </developers>
  ...
</project>

Am besten verweist die E-Mail-Adresse auf ein allgemeines Postfach wie security@yourdomain.com. So erreichen Nachrichten weiterhin einen überwachten Posteingang, falls die für Sicherheit zuständige Kontaktperson einmal ausfällt.

9. Halten Sie sich auf dem neuesten Stand

Wie immer enthalten neuere Versionen Sicherheitsupdates. Halten Sie daher Maven auf dem neuesten Stand, um das Risiko zu verringern, mit einer Version zu arbeiten, die eine Sicherheitslücke enthält. Meiden Sie insbesondere Maven 3.0.4, da diese Version ein kritisches Sicherheitsproblem enthält, durch das Zertifikate bei HTTPS-Verbindungen ignoriert werden. Die aktuelle Maven-Version finden Sie auf der Maven-Downloadseite.

10. Prüfen Sie Sicherheitsbulletins

Das Maven-Team informiert Sie auf der Apache-Maven-Website in Sicherheitsbulletins über Probleme. Als das Snyk-Sicherheitsteam kürzlich zahlreiche Fälle der Zip-Slip-Sicherheitslücke entdeckte, veröffentlichte das Apache-Team – das mit großem Einsatz mit uns zusammenarbeitete, um Zip-Slip-Fälle in Apache-Projekten zu beseitigen – das folgende Bulletin auf der Apache-Maven-Website:

Abonnieren Sie unbedingt die Mailingliste announce@maven.apache.org und/oder folgen Sie @ASFMavenProject auf Twitter, um Neuigkeiten aus dem Apache-Maven-Projekt zu erhalten.

Damit sind unsere 10 Best Practices für die Sicherheit von Apache Maven abgeschlossen. Laden Sie diesen Spickzettel herunter und hängen Sie ihn in Ihrer Nähe auf, damit Sie bei Ihren Builds immer an Sicherheit denken!

SPICKZETTEL HERUNTERLADEN!

Drucken Sie den Spickzettel aus und hängen Sie ihn gut sichtbar auf. So werden Sie an einige der Best Practices erinnert, die Sie als Maven-Entwickler befolgen sollten.