PHP-4-Code ist ein Zeitdokument. Er stammt aus einer Phase, in der PHP noch nicht das durchdachte Werkzeug von heute war, sondern eine pragmatische Sprache, die vor allem schnell zum Ergebnis führen sollte. Manche Entscheidungen aus dieser Zeit gelten heute nicht nur als überholt, sondern als handfestes Sicherheitsrisiko. Sie wurden längst aus der Sprache entfernt – leben aber in alten Anwendungen weiter.
Wer eine PHP-4-Anwendung modernisieren will, muss diese Altlasten kennen. Drei davon sind besonders hartnäckig.
register_globals: die offene Tür
register_globals war bequem und gefährlich zugleich. War es aktiviert, machte PHP aus jedem Formular- und URL-Parameter automatisch eine gleichnamige Variable im Code. Man konnte also einen Wert aus einem Formular nutzen, ohne ihn je bewusst entgegenzunehmen – er war einfach da.
Das Problem: Ein Angreifer konnte auf demselben Weg Variablen setzen, die der Entwickler für intern und sicher hielt. Eine Variable, die etwa darüber entschied, ob jemand angemeldet ist, ließ sich von außen beeinflussen. Aus Bequemlichkeit wurde so eine Hintertür. register_globals wurde später standardmäßig abgeschaltet und schließlich ganz aus PHP entfernt – aber Code, der sich darauf verlässt, funktioniert ohne diese Krücke nicht mehr und muss umgeschrieben werden.
magic_quotes: die vergiftete Hilfe
magic_quotes sollte gut gemeint vor SQL-Injection schützen, indem PHP eingehende Daten automatisch mit Backslashes versah. In der Praxis war es ein Eigentor. Es vermittelte falsche Sicherheit, funktionierte uneinheitlich, und vor allem hinterließ es Spuren in den Daten.
Über Jahre wanderten so verunreinigte Werte in die Datenbank – Texte mit zusätzlichen Backslashes, doppelt escapte Zeichen, kaputte Sonderzeichen. Diese Verunreinigung ist tückisch, weil sie sich im Bestand festsetzt und auch dann bleibt, wenn magic_quotes längst abgeschaltet ist. Wer eine alte Anwendung migriert, ohne diese Daten zu bereinigen, schleppt das Problem mit.
Die alten Datenbankfunktionen
PHP 4 sprach Datenbanken über die mysql_*-Funktionen an – mysql_query, mysql_connect und Verwandte. Sie luden geradezu dazu ein, Abfragen als Strings aus Nutzereingaben zusammenzubauen, mit allen Injection-Risiken, die daraus folgen. Diese Funktionen wurden mit neueren PHP-Versionen abgekündigt und schließlich komplett aus der Sprache entfernt. Das ist einer der Hauptgründe, warum sich eine PHP-4-Anwendung nicht einfach auf eine aktuelle PHP-Version heben lässt: Der Datenbankzugriff funktioniert dort schlicht nicht mehr.
Warum man das nicht „mitnehmen“ darf
Es ist verlockend, bei einer Migration nur das Nötigste anzufassen und den Rest unverändert zu übernehmen. Bei diesen Altlasten wäre das ein Fehler. Sie sind keine kosmetischen Eigenheiten, sondern offene Risiken und kaputte Daten. Eine Modernisierung, die sie mitschleppt, ist nur halb gemacht.
Wie wir die Altlasten auflösen
Bei der Migration auf Laravel mit aktuellem PHP werden diese Punkte gezielt erledigt:
- register_globals wird aufgelöst, indem jeder Zugriff auf Eingaben explizit und kontrolliert gemacht wird – keine magischen Variablen mehr, die aus dem Nichts auftauchen.
- Die magic_quotes-Verunreinigung in den Daten wird zuerst diagnostiziert und dann automatisiert bereinigt, über einen eigenen Artisan-Befehl statt mühsamer Handarbeit an tausenden Datensätzen.
- Die alten mysql_-Aufrufe weichen dem sauberen Datenbankzugriff über Eloquent, der Abfragen grundsätzlich parametrisiert aufbaut und damit Injection an der Wurzel verhindert.
Mehr dazu auf der Seite zur PHP-Migration und im Detail unter PHP 5 zu Laravel migrieren – das dort beschriebene Vorgehen gilt für PHP-4-Bestände erst recht.
Der erste Schritt
Im Code-Assessment bestimmen wir, welche dieser Altlasten Ihre Anwendung trägt und wie aufwendig ihre Auflösung wäre.
Häufige Fragen
Wir wissen nicht, ob magic_quotes je aktiv war. Lässt sich das feststellen? Ja. Die typischen Spuren in den Daten sind erkennbar, und genau danach suchen wir in der Analyse.
Kann man die Daten nicht einfach so lassen? Solange die Anwendung läuft, fällt es oft nicht auf. Aber bei jeder Weiterverarbeitung, jedem Export oder jeder neuen Oberfläche kommen die verunreinigten Werte ans Licht. Sauberer ist, sie einmal richtig zu bereinigen.
Ist PHP 4 wirklich noch im Einsatz? Häufiger, als man denkt. Und selbst PHP-5-Anwendungen tragen viele dieser Altlasten, weil sie aus derselben Ära stammen.
Quellen
- PHP.net – Supported Versions / Release-Policy: https://www.php.net/supported-versions.php
Dieser Beitrag ist ein informativer Überblick und keine Rechtsberatung.