Sicherheit erhöhen, wenn ein Full-Upgrade (noch) nicht geht

Ein Full-Upgrade ist die sauberste Lösung – aber selten die, die gerade realistisch ist. Vielleicht hängt die Anwendung an PHP 7.4, das Framework ist zwei Major-Versionen zurück, und ein Sprung würde Wochen an Regressionstests bedeuten. Das heißt aber nicht, dass Sie mit den Risiken leben müssen. PHP Sicherheit ohne Upgrade ist kein Notnagel, sondern eine legitime Zwischenstufe: Sie senken das Angriffsrisiko deutlich, ohne die über Jahre bewährte Fachlogik anzufassen.

Wichtig vorab: Ein System, das seit Jahren zuverlässig läuft, ist kein Müll. Es ist der Beweis, dass die Geschäftslogik funktioniert. Angreifbar ist fast nie diese Logik, sondern der Code drumherum – veraltete Abhängigkeiten, fehlende Header, offene Konfiguration. Genau dort setzen die folgenden Maßnahmen an.

Warum PHP Sicherheit ohne Upgrade überhaupt funktioniert

Die meisten realen Angriffe zielen nicht auf einen exotischen Bug im PHP-Core, sondern auf bekannte Schwachstellen im Ökosystem: verwundbare Composer-Pakete, SQL-Injection durch string-konkatenierte Queries, Cross-Site-Scripting in Templates, unsichere Session-Konfiguration. All das lässt sich adressieren, ohne die PHP-Version zu wechseln.

Warum lässt sich eine alte PHP-Anwendung ohne Versionssprung absichern?
Weil die häufigsten Einfallstore auf der Anwendungs- und Konfigurationsebene liegen, nicht in der PHP-Version selbst. Eine gehärtete Konfiguration, gepatchte Abhängigkeiten und ein WAF-Layer schließen die Mehrheit der praktisch ausgenutzten Lücken.

Das entbindet Sie nicht vom späteren Upgrade – vor allem, wenn Ihre PHP-Version keine Security-Fixes mehr erhält. Aber es verschafft Ihnen den Puffer, das Upgrade geplant und ohne Panik anzugehen.

Zuerst: Wissen, was verwundbar ist

Bevor Sie irgendetwas härten, brauchen Sie einen ehrlichen Blick auf den Ist-Zustand. Zwei Kommandos liefern in Minuten mehr Erkenntnis als jedes Bauchgefühl:

• composer audit – prüft Ihre installierten Pakete gegen die bekannte Advisory-Datenbank und listet konkrete CVEs samt betroffener Version.
• composer outdated --direct – zeigt, welche direkten Abhängigkeiten hinterherhinken, ohne Sie mit transitiven Paketen zu erschlagen.

Der entscheidende Punkt: Sie müssen nicht alles aktualisieren. Sie aktualisieren gezielt die Pakete mit gemeldeten Sicherheitslücken. Ein Patch-Update (composer update monolog/monolog --with-dependencies im Rahmen der erlaubten Version) ändert in aller Regel kein öffentliches Verhalten und ist damit risikoarm. Genau diese chirurgischen Updates sind der Kern von PHP Sicherheit ohne Upgrade.

Die Konfiguration härten – oft die größte Wirkung pro Aufwand

Viele Altanwendungen laufen mit einer php.ini, die nie überprüft wurde. Ein paar Einstellungen kosten Minuten und schließen ganze Angriffsklassen aus:

• expose_php = Off – entfernt die PHP-Version aus dem X-Powered-By-Header und macht die gezielte Suche nach passenden Exploits schwerer.
• display_errors = Off in Produktion – verhindert, dass Stacktraces und Pfade dem Angreifer Ihre Struktur verraten. Fehler gehören ins Log, nicht in die Antwort.
• session.cookie_httponly = 1 und session.cookie_secure = 1 – schützen das Session-Cookie vor JavaScript-Zugriff und erzwingen HTTPS.
• session.cookie_samesite = Lax – reduziert die Angriffsfläche für CSRF.

Auf Webserver-Ebene ergänzen Sie Security-Header, die unabhängig von PHP wirken: eine Content-Security-Policy (auch eine restriktive Basis-Policy hilft gegen XSS), X-Content-Type-Options: nosniff und Strict-Transport-Security. Testen Sie eine CSP anfangs im Content-Security-Policy-Report-Only-Modus, damit Sie nichts Bestehendes brechen.

Die gefährlichen Klassiker gezielt entschärfen

Zwei Schwachstellen dominieren bei Legacy-PHP: SQL-Injection und XSS. Beide lassen sich lokal beheben, ohne die Architektur anzufassen.

Gegen SQL-Injection ersetzen Sie zusammengesetzte Query-Strings durch Prepared Statements. Sie müssen dafür nicht die ganze Datenschicht umschreiben – gehen Sie über grep die Stellen durch, an denen Nutzereingaben in Queries fließen (Suche nach $_GET, $_POST, $_REQUEST in Kombination mit query( oder mysqli_query), und heben Sie genau diese auf gebundene Parameter. Das ist punktuelle, gut testbare Arbeit.

Gegen XSS stellen Sie sicher, dass jede Ausgabe von Nutzerdaten kontextgerecht escaped wird – in reinem PHP über htmlspecialchars($wert, ENT_QUOTES, 'UTF-8'), in Twig über die automatische Ausgabe-Filterung (prüfen Sie kritisch jeden |raw-Filter). Auch das ist lokal, ohne Framework-Sprung.

Einen Schutzschild vor die Anwendung setzen

Wenn Sie den Code selbst nur begrenzt anfassen können, verlagern Sie einen Teil der Verteidigung nach vorn. Eine Web Application Firewall filtert bekannte Angriffsmuster, bevor sie PHP überhaupt erreichen. Das ist besonders wertvoll, wenn Sie mit einer PHP-Version arbeiten, die keine offiziellen Security-Fixes mehr bekommt.

• ModSecurity mit dem OWASP Core Rule Set – ein bewährter, quelloffener Filter für gängige Injection- und Scanning-Muster, vor Apache oder Nginx betrieben.
• Ein vorgelagerter Dienst (etwa eine Cloud-WAF oder ein Reverse Proxy) – nimmt zusätzlich Rate-Limiting und Bot-Filterung ab.

Eine WAF ersetzt kein Härten des Codes. Sie kauft Ihnen Zeit und fängt breit gestreute, automatisierte Angriffe ab – und die machen den Großteil des Traffics auf verwundbaren Altsystemen aus.

Zugänge und Secrets aufräumen

Der unspektakulärste, aber häufig wirksamste Schritt: Zugänge kontrollieren. Prüfen Sie, ob Datenbank-Passwörter oder API-Keys im Repository liegen, ob es alte Admin-Accounts ohne Zweck gibt, ob das Backend über eine offene, ratenlimitierte Login-Seite erreichbar ist. Ein starkes Passwort-Hashing über password_hash() mit PASSWORD_DEFAULT gehört ebenso dazu wie das Sperren nach zu vielen Fehlversuchen. Diese Maßnahmen sind unabhängig von Ihrer PHP-Version und kosten wenig.

Ehrlicher Praxis-Tipp zum Schluss

Fangen Sie mit der Messung an, nicht mit dem Refactoring. Führen Sie composer audit aus, härten Sie die Konfiguration, setzen Sie eine WAF davor – in dieser Reihenfolge liegt das beste Verhältnis von Wirkung zu Risiko. Und seien Sie ehrlich zu sich: Läuft Ihre PHP-Version bereits ohne Security-Support, ist all das eine Brücke, kein Dauerzustand. Die Maßnahmen verschaffen Ihnen den Spielraum, das eigentliche Upgrade sauber vorzubereiten, statt es unter Druck zu erzwingen.

Genau bei dieser Gratwanderung – absichern, was läuft, und das Upgrade fundiert vorbereiten – unterstützt LegacyWerk, wenn Sie einen zweiten Blick von außen brauchen.