PHP-Composer-Sicherheitslücken mit Snyk testen
DeveloperSteve Coochin
20. Mai 2021
0 Min. LesezeitPHP wird häufig für Websites eingesetzt. Von Blogs bis hin zum E-Commerce ist die Sprache in unseren Alltag eingebettet und treibt einen Großteil des Internets an, das wir heute nutzen. Laut einem Wappalyzer-Bericht zu den führenden Programmiersprachen 2020 hält PHP heute einen Anteil von 79 % an den Backend-Sprachen, die im Internet verwendet werden.
Eine der größten Herausforderungen bei PHP-Bibliotheken war über die Jahre hinweg die Paketverwaltung. Es gab einige Möglichkeiten, Bibliotheken einfach zu installieren und zu verwalten, darunter PECL und CPAN. Erwähnenswert ist auch PEAR, das 2009 eingeführt wurde und zu den ersten Möglichkeiten gehörte, Bibliotheken zu laden und zu verteilen. Daraus wurde später PEAR2, das schließlich Teil von PHP Composer wurde (inzwischen im neunten Jahr!). Genau das sehen wir uns heute an.
Was ist PHP Composer?
PHP Composer ist ein Paketverwaltungstool, mit dem Sie Bibliotheken und Abhängigkeiten in PHP installieren und aktualisieren können. Es wurde schnell populär, weil es Bibliotheken und Abhängigkeiten in Frameworks und Projekten lädt und verwaltet. Das Tool wird über die Befehlszeile gesteuert und ermöglicht Ihnen, PHP-Anwendungen, Bibliotheken und Abhängigkeiten mit Autoload-Funktionen in Projekten zu installieren. Wichtig ist: PHP Composer installiert nichts global.
PHP-Composer-Sicherheit im Überblick
PHP Composer beschleunigt zwar die App-Entwicklung, nimmt Ihnen aber ein gewisses Maß an Kontrolle und Transparenz. Das Programmieren wird dadurch einfacher, aber es stellt sich die Frage: Ist das auch sicher? Mit Snyk kann ich diese Frage mit wenigen Klicks beantworten.
Bevor wir uns einige konkrete Implementierungen von PHP Composer ansehen, möchte ich auf ein paar Dinge hinweisen.
Als Nutzer und Entwickler dieser Plattformen war ich aus verschiedenen Gründen überrascht von meinen Ergebnissen. Das bestätigt, wie wichtig es ist, kontinuierlich für mehr Bewusstsein und Wissen zu sorgen, um sichere Software zu entwickeln.
In allen folgenden Fällen habe ich mich an die jeweiligen Communities gewandt, um die Sicherheitslücken zu besprechen und darauf aufmerksam zu machen, sofern sie dort noch nicht bekannt waren (viele waren bereits behoben).
Kirby
Um mit Kirby und Composer loszulegen, folgen Sie einfach der Einrichtungsanleitung in der Dokumentation „Kirby meets Composer“:
Composer installiert die neueste Kirby-Version (3.3.5), für die in der Snyk Vulnerability DB nur eine Sicherheitslücke mit mittlerem und eine mit niedrigem Schweregrad aufgeführt sind. Die Snyk CLI findet jedoch ein Problem bei einer Abhängigkeit: PHPMailer verwendet Version 6.2.0. Für diese Version von PHP Mailer ist eine Sicherheitslücke mit hohem Schweregrad für Cross-Site-Scripting bekannt.
Zum Zeitpunkt der Veröffentlichung ist das Problem in PHPMailer 6.4.1 behoben. Sie können es beheben, indem Sie composer upgrade ausführen und auf die neueste Version aktualisieren. Ein Blick auf die Entwicklungsgeschichte des Moduls zeigt eine lange Reihe von Sicherheitslücken. Deshalb empfehlen wir dringend, regelmäßig mit Snyk Code zu scannen, damit Sie über neu entdeckte Sicherheitslücken informiert werden.
Joomla
Das Joomla-Repository enthält eine Composer-Datei, die alle für den Betrieb erforderlichen Abhängigkeiten installiert. Bei einem Scan mit der Snyk CLI finden wir zwei Probleme und vier anfällige Pfade.
Dabei finden wir erneut PHP Mailer, das Version 5.2.28 installiert. Diese Version weist eine fehlerhafte Eingabevalidierung auf. Snyk zeigt, dass das Problem in Version 6.1.6 behoben ist.
Snyk hat außerdem eine Man-in-the-Middle-Sicherheitslücke (MITM) entdeckt, die über `paragoine/random_compat` in Version 1.4.3 eingebunden wird und mit `joomla/session` zusammenhängt. MITM-Angriffe sind äußerst gefährlich, da sie das elektronische Abhören ermöglichen. Weitere Informationen zu dieser Art von Sicherheitslücke finden Sie in unserem Blog zu Man-in-the-Middle-Angriffen.
Drupal
Mithilfe der praktischen Anleitung im Drupal-Repository können wir mit dem neuesten Entwicklungszweig 9.x schnell loslegen.
Während die Installation läuft, können wir in der Snyk Vulnerability Database nach bekannten Problemen suchen. Dort finden Sie auch Sicherheitslücken in früheren Drupal-Versionen, auf die Sie achten sollten. Anschließend zeigt ein Scan mit der Snyk CLI, dass Version 9.x keine Probleme aufweist. Zur Sicherheit prüfen wir auch Drupal 8.x – auch hier gibt es keine Probleme. Sehr gut!
Nachdem diese beiden Versionen geprüft sind, testen wir auch Drupal 7, das noch recht häufig verwendet wird. Klonen Sie dazu das Drupal-7.x-Repository.
Beim Scan von 7.x fallen die Ergebnisse der Snyk CLI etwas anders aus: neun Sicherheitslücken und 18 anfällige Pfade. Die Bandbreite reicht von Dateiupload-Exploits über DoS bis hin zu Remote Code Execution (RCE) und beliebiger Codeausführung (ACE).
Auf Grundlage dieser Ergebnisse empfehle ich Ihnen, mindestens auf 8.x zu aktualisieren, um Ihre Drupal-Implementierung zu schützen.
Unterstützen Sie die Communities mit eigenen Beiträgen
Als ich anfing, einige dieser weitverbreiteten Plattformen zu testen, wusste ich nicht, was mich erwarten würde. Wie bereits erwähnt, waren die Ergebnisse ziemlich überraschend. Entwickler, Teams oder Unternehmen, die diese Plattformen in der Produktion einsetzen, wissen möglicherweise nicht, was genau sie sich damit ins Haus holen. Ich hoffe, dass dieser Blog mehr Teams dabei hilft, sicher zu bleiben.
Aber ich bin nur ein Entwickler, und dies ist nur ein Blog. Damit wir wirklich viel für die Sicherheit erreichen, möchte ich Sie alle ermutigen, Projekte selbst zu testen und zu den Fehlerbehebungen beizutragen. Hinter diesen großartigen Communities stehen oft engagierte Entwickler, die Dinge schaffen möchten, die Menschen auf der ganzen Welt helfen. Sie brauchen Ihre Unterstützung.
Starten Sie mit Capture-the-Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Challenges lösen.


