Altlasten im PHP-Code: Wo der Schuh drückt
SQL-Injection, XSS, Session-Fixation. Wer seit Jahren mit PHP-Projekten zu tun hat, kennt das Trio. Die Lücken tauchen immer wieder auf, besonders in Anwendungen, die nie einen gründlichen Frühjahrsputz erlebt haben. Dort gammeln sie vor sich hin – bis plötzlich Daten rausgehen oder Nutzer-Sessions übernommen werden. Klassiker.
Was fehlt oft? Ein klarer Schnell-Check, mit dem sich bestehende Projekte abklopfen lassen. Nicht jeder will oder kann gleich refactoren. Also: Wie prüft man möglichst ohne Riesenaufwand, wo es gefährlich wird?
SQL-Injection: Der alte Bekannte
Noch immer ein Dauerbrenner. Wer in alten Projekten nachschaut, findet schnell: $_GET und $_POST landen direkt in SQL-Strings. Mal eben in WHERE-Klauseln, ohne jede Absicherung. Besonders fies: mysql_query oder mysql_* überall – prepared Statements? Fehlanzeige. PDO oder MySQLi werden selten nachgerüstet.
Kurze Checkliste:
- Stecken irgendwo Inputs ungefiltert im SQL?
- Gibt’s überhaupt Prepared Statements? Oder noch alles wie 2008?
- Finden sich noch mysql_query und Konsorten?
Schnelle Hilfe: Alles auf Prepared Statements umstellen, Eingaben vorher prüfen. Wer hier schlampt, merkt es oft erst, wenn der Dump auf Pastebin landet. Passiert öfter, als gedacht.
XSS: Ungefilterte Ausgabe, großes Kino für Angreifer
XSS kommt leise, bleibt aber hartnäckig. Nutzerinput landet im HTML, fertig ist das Scriptkiddie. Typische Orte: Kommentare, Suchfelder, Profilseiten. Wer nicht überall htmlspecialchars samt ENT_QUOTES und UTF-8 einsetzt, hat ein Problem. Fehlen dann noch CSP-Header, wird’s richtig sportlich.
Erlebt: In einem älteren Projekt reichte der nachgezogene CSP-Header, um das schlimmste XSS-Risiko zu bremsen. Nicht perfekt, aber besser als nix.
Session-Fixation: Wenn die ID alt bleibt
Wird gerne vergessen, ist aber ein gefährliches Einfallstor. Angreifer bringen eigene Session-IDs ins Spiel, übernehmen nach Login die Identität. Wer nach Login die Session-ID nicht erneuert (session_regenerate_id), lädt quasi ein. Session-Cookies ohne Secure, HttpOnly, SameSite? Kommt öfter vor, als angenehm. HTTPS fehlt bei Altprojekten sowieso noch oft.
Praxiskontrolle:
- Session-ID nach Authentifizierung neu? Oder bleibt alles beim Alten?
- Cookies sauber gesetzt?
- Irgendwo noch HTTP ohne S?
Meine Einschätzung nach fast 30 Jahren Webentwicklung
Altprojekte werden selten grundlegend überarbeitet. Agenturen und Einzelkämpfer schieben Security-Checks, weil „läuft doch“. Bis der erste Vorfall den Anwalt auf den Plan ruft. Ein OWASP-Check ist kein Hexenwerk und spart am Ende teure Fehler.
Für Teams mit 5–10 Leuten: Einen halben Tag investieren, Code einmal abklopfen – besser als nachher die Kunden beruhigen. Freelancer haben meist eh keinen Rechtsbeistand in der Hinterhand. Aufwand: überschaubar. Wirkung: hoch.
Was sich in der Praxis durchgesetzt hat:
- Prepared Statements als Pflicht, nie rohe Inputs
- HTML-Ausgabe immer escapen, Header setzen
- Session-Handling nach Login härten, Cookies vernünftig absichern, HTTPS als Standard
Checkliste für Altprojekte (Stand 2026)
1. SQL prüfen:
- Keine direkten Input-Variablen im SQL
- Nur noch PDO oder MySQLi mit Prepared Statements
- Alte mysql_* rauswerfen
2. HTML-Ausgabe prüfen:
- htmlspecialchars (ENT_QUOTES, UTF-8) überall
- CSP und X-XSS-Protection setzen
3. Session-Handling prüfen:
- session_regenerate_id() nach Login
- Secure, HttpOnly, SameSite für Cookies
- HTTPS wirklich überall
4. Fehlerausgaben stilllegen – keine Details nach außen
5. PHP-Version: Mindestens 8.1 – alles darunter ist für Security-Fixes raus
Fazit
SQL-Injection, XSS, Session-Fixation – das Trio spukt noch in zu vielen PHP-Projekten herum. Mit ein paar Stunden und gezieltem Blick lassen sich die meisten Probleme erschlagen. Kein Hexenzauber, einfach Pflichtprogramm – bevor es richtig weh tut. Wer die Checkliste regelmäßig nutzt, schläft ruhiger.
Serie geht weiter: Teil 4: PHP-Sicherheit: OWASP-Basics, Teil 6: OPcache und Performance.
bye
mo
Zuletzt bearbeitet: