PHP-Anwendungen absichern — die Lücken, die wirklich ausgenutzt werden.

Die häufigsten Lücken.

Eingeschleuster Datenbankcode.

Wenn Eingaben von Besuchern direkt in Datenbankabfragen eingesetzt werden, kann ein Angreifer eigene Befehle einschleusen — und damit Daten auslesen, verändern oder löschen. Das ist eine der ältesten und immer noch eine der häufigsten Lücken.

Der Schutz ist eindeutig: vorbereitete Anweisungen, bei denen Abfrage und Daten getrennt an die Datenbank gehen. Moderne Frameworks nutzen sie standardmäßig. In alten Anwendungen finden sich oft Abfragen, in die Werte direkt eingesetzt werden — jede davon ist ein mögliches Einfallstor (Altprojekt).

Eingeschleuste Skripte.

Wenn Eingaben ungeprüft wieder ausgegeben werden — etwa ein Name, ein Kommentar, ein Suchbegriff —, kann ein Angreifer Skripte einschleusen, die im Browser anderer Nutzer laufen. Damit lassen sich Sitzungen übernehmen oder Inhalte fälschen.

Der Schutz: Jede Ausgabe wird passend zum Zusammenhang maskiert. Vorlagensysteme moderner Frameworks tun das automatisch. Zusätzlich hilft eine Sicherheitsrichtlinie für Inhalte, die festlegt, von wo Skripte geladen werden dürfen.

Gefälschte Formularanfragen.

Ein angemeldeter Nutzer besucht eine fremde Seite, die im Hintergrund eine Anfrage an deine Anwendung schickt — etwa eine Passwortänderung. Weil der Nutzer angemeldet ist, führt die Anwendung sie aus.

Der Schutz: Jedes Formular enthält einen geheimen Wert, den nur die eigene Anwendung kennt. Anfragen ohne diesen Wert werden abgelehnt. Laravel erledigt das automatisch, in Eigenbauten fehlt es oft.

Dateiuploads.

Uploads sind ein beliebtes Einfallstor: Ein Angreifer lädt statt eines Bildes eine PHP-Datei hoch und ruft sie anschließend auf. Damit hat er die Kontrolle über den Server.

• Dateityp anhand des Inhalts prüfen, nicht nur der Endung.
• Eigene Dateinamen vergeben.
• Außerhalb des öffentlichen Verzeichnisses speichern oder Ausführung dort verbieten.
• Größe begrenzen.

Bei Websites, die gehackt wurden, finde ich die Einstiegsstelle erstaunlich oft in einem Upload-Formular (Website gehackt).

Zugangsdaten und Konfiguration.

Datenbankpasswörter, Schlüssel für Schnittstellen und Mailzugänge gehören nicht in den Code, sondern in eine Konfiguration außerhalb des öffentlichen Verzeichnisses. Und nicht in die Versionsverwaltung.

Ein häufiger Fund: Eine Konfigurationsdatei liegt im öffentlichen Verzeichnis und lässt sich im Browser aufrufen. Oder eine Sicherungskopie mit der Endung .bak liegt daneben und wird als Text ausgeliefert. Beides ist schnell geprüft und schnell behoben.

Dazu gehört: Fehlermeldungen im Betrieb nicht anzeigen. Detaillierte Fehlermeldungen verraten Pfade, Abfragen und manchmal Zugangsdaten (Fehlerprotokoll).

Passwörter und Sitzungen.

• Passwörter nur mit den eingebauten, modernen Funktionen speichern — nie mit veralteten Verfahren.
• Sitzungen nach der Anmeldung erneuern.
• Cookies nur über verschlüsselte Verbindungen und nicht für Skripte zugänglich.
• Anmeldeversuche begrenzen.
• Zwei-Faktor-Anmeldung für Verwaltungsbereiche.

Alte Anwendungen speichern Passwörter oft mit veralteten Verfahren. Eine Umstellung ist möglich, ohne dass alle Nutzer neue Passwörter brauchen — beim nächsten Anmelden wird das Passwort neu gespeichert.

Abhängigkeiten und PHP.

Bibliotheken und Frameworks haben gelegentlich Sicherheitslücken, die mit Updates geschlossen werden. Die Abhängigkeitsverwaltung kann bekannte Lücken in den eingesetzten Versionen melden — diese Prüfung gehört regelmäßig ausgeführt.

Dasselbe gilt für PHP selbst: Eine Version ohne Support bekommt keine Sicherheitskorrekturen mehr (PHP-Versionen).

Server.

• Nur das öffentliche Verzeichnis erreichbar machen.
• Verschlüsselte Verbindung überall (SSL).
• Sicherheitsheader setzen.
• Dateirechte so eng wie möglich.
• Sicherungen getrennt vom Server.

Eine Prüfung.

Eine Sicherheitsprüfung einer bestehenden PHP-Anwendung umfasst: Durchsicht des Codes auf die genannten Muster, Prüfung der Abhängigkeiten auf bekannte Lücken, Prüfung der Konfiguration und des Servers, Test von außen.

Das Ergebnis ist eine Liste nach Dringlichkeit — mit dem, was sofort behoben werden sollte, und dem, was in die normale Pflege gehört. Ich bin kein zertifizierter Penetrationstester; für Anwendungen mit sehr hohem Schutzbedarf gehört zusätzlich ein spezialisierter Prüfer dazu.

Wenn du nicht weiterkommst.

Wenn du wissen willst, wie sicher deine PHP-Anwendung ist, oder Lücken schließen lassen musst. Ich sehe mir den Code an, sage dir, wo die Risiken liegen, und setze um, was nötig ist. Die Übersicht findest du unter PHP und Laravel; wenn es eilt, hilft der Notfall-Support.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. PHP ist die Sprache, in der ich seit Jahren am meisten Code schreibe — in WordPress-Plugins, Shop-Erweiterungen, Schnittstellen und eigenständigen Anwendungen mit Laravel. Ich unterrichte Webentwicklung als Dozent und kenne PHP vom alten prozeduralen Skript bis zur modernen, typisierten Anwendung mit Tests.

Gerade bei bestehenden Anwendungen zählt das: Ich lese fremden Code schnell, erkenne, wo er gegen die Sprache arbeitet, und sehe, was sich mit vertretbarem Aufwand retten lässt. Viele PHP-Projekte, die als hoffnungslos gelten, sind es nicht — sie wurden nur lange nicht gepflegt.

Was du bekommst: eine ehrliche Einschätzung, ob sich modernisieren oder neu bauen lohnt, sauberen Code, den auch andere Entwickler verstehen, und eine Dokumentation — auch wenn die Antwort lautet, dass die Anwendung so bleiben kann.