So bereinigen Sie Benutzereingaben in PHP: 7 fatale Fehler und ihre Lösungen

Einleitung: Warum Ihre PHP-Website gerade jetzt gehackt werden könnte?

Stellen Sie sich vor: Sie haben eine coole Website mit PHP erstellt, ein Kontaktformular, Kommentare, einen persönlichen Bereich. Alles funktioniert. Aber eines Tages gehen Sie ins Admin-Panel und es ist leer. Oder noch schlimmer: Auf der Website erscheint Casino-Werbung und Google hat Ihre Seite blockiert. Kommt Ihnen das bekannt vor? Die Wurzel des Übels ist die falsche Verarbeitung von Benutzereingaben.

Die Frage "How can I sanitize user input with PHP?" ist eine der beliebtesten auf Stack Overflow. Tausende Entwickler stolpern über die gleichen Fallstricke. In diesem Artikel analysieren wir die häufigsten Fehler, die selbst erfahrene Programmierer machen, und zeigen, wie man sie vermeidet. Sie erfahren, wie Sie sich vor XSS, SQL-Injection und anderen Angriffen schützen. Los geht's!

Fehler Nr. 1: Verwendung von mysql_real_escape_string() für alles

Alte Schule: Viele Entwickler denken immer noch, dass das Problem gelöst ist, wenn man alle Daten in mysql_real_escape_string() verpackt. Das ist ein grober Fehler. Diese Funktion ist nur zum Escapen von Strings in SQL-Abfragen gedacht, und das auch nur für die veraltete Erweiterung mysql_*, die bereits in PHP 7 entfernt wurde.

Beispiel für falschen Code:

<?php\n$name = mysql_real_escape_string($_POST['name']);\n$query = "INSERT INTO users (name) VALUES ('$name')";\n$result = mysql_query($query);\n?>

Warum das schlecht ist:

\n
• Die Funktion schützt nicht vor XSS-Angriffen (z. B. Einschleusen von JavaScript).
\n
• Die Erweiterung mysql_* ist veraltet und unsicher.
\n
• Sie vermischen die Escape-Logik mit der Geschäftslogik.
\n

So beheben Sie es: Verwenden Sie Prepared Statements über PDO oder MySQLi. Und für die Ausgabe von Daten auf dem Bildschirm eine separate Bereinigung.

Fehler Nr. 2: Ignorieren von XSS-Angriffen bei der Datenausgabe

Der häufigste Fehler. Sie nehmen Daten entgegen, speichern sie in der Datenbank und geben sie einfach mit echo oder print aus. Voilà – ein Angreifer kann ein Skript einfügen, das Cookies stiehlt, den Benutzer umleitet oder das Layout beschädigt.

Beispiel für anfälligen Code:

<?php\necho "<p>Hallo, " . $_GET['name'] . "!</p>";\n?>

Wenn in der URL ?name=<script>alert('XSS')</script> übergeben wird, wird das Skript ausgeführt.

Lösung: Verwenden Sie die Funktion htmlspecialchars() mit dem Parameter ENT_QUOTES:

<?php\n$name = htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');\necho "<p>Hallo, " . $name . "!</p>";\n?>

Wichtig: Die Bereinigung sollte genau zum Zeitpunkt der Ausgabe erfolgen, nicht beim Speichern. Wenn Sie Zeichen in der Datenbank ersetzen, verlieren Sie die Originaldaten.

Fehler Nr. 3: Blindes Filtern mit strip_tags()

Viele denken: "Oh, ich entferne einfach alle HTML-Tags – dann ist alles gut." Aber strip_tags() ist kein Allheilmittel. Erstens entfernt es nur Tags, lässt aber Attribute (z. B. onclick) stehen. Zweitens, wenn Sie bestimmte Tags erlauben müssen (z. B. <b> oder <i>), wird strip_tags() unpraktisch.

Beispiel:

<?php\n$comment = strip_tags($_POST['comment']);\necho $comment; // Entfernt <script>, lässt aber <a onclick="..."> stehen\n?>

Lösung: Verwenden Sie htmlspecialchars() für normalen Text oder Bibliotheken wie HTML Purifier, wenn bestimmte Tags erlaubt werden sollen. HTML Purifier prüft nicht nur Tags, sondern auch Attribute, Styles und sogar CSS.

Fehler Nr. 4: Fehlende Validierung von E-Mail, URL und Zahlen

Bereinigung betrifft nicht nur XSS. Wenn Sie eine E-Mail erwarten, aber den String "123" erhalten, kann das Fehler verursachen. Oder wenn Sie eine URL ohne Prüfung speichern, kann ein Angreifer javascript:alert(1) einfügen.