DE
RU
EN
ES
ZH
FR
PT
AR
HI
Ihr PHP-Code im Visier: Warum Schweigen nicht Gold ist
\n\nStellen Sie sich vor: Sie haben eine Website gestartet, alles läuft wie am Schnürchen, die Kunden sind zufrieden. Und währenddessen gibt irgendwo in einer dunklen Ecke des Internets ein Script-Kiddie in Ihr Suchformular die magische Zeichenfolge ' OR 1=1 -- ein. Und die Datenbank, wie ein gehorsamer Diener, gibt ihm alle Benutzerpasswörter preis. Eine bekannte Geschichte? Leider ja, für viele angehende Entwickler.
Sicherheit in PHP ist keine langweilige Bürokratie, sondern der reale Schutz Ihrer Zeit, Ihres Geldes und Ihres Rufs. Heute befassen wir uns mit zwei Hauptfeinden von Webanwendungen: SQL-Injection und Cross-Site-Scripting (XSS). Sie erfahren, wie Sie sie erkennen, entschärfen und in Ihrem Code nie wieder zulassen.
\n\nSQL-Injection: Wenn der Benutzer zum Hacker wird
\n\nSQL-Injection ist ein Angriff, bei dem ein Angreifer bösartigen SQL-Code über Eingabefelder „einschleust". Wenn Sie Benutzerdaten einfach in Ihre Abfrage einfügen, können Sie genauso gut selbst dem Einbrecher die Tür öffnen.
\n\nWie anfälliger Code aussieht
\n\nHier ist ein klassisches Beispiel, das immer noch in alten Lehrbüchern und auf aktiven Websites zu finden ist:
\n\n<?php\n// GEFÄHRLICH! Machen Sie das niemals\n$username = $_POST['username'];\n$password = $_POST['password'];\n\n$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";\n$result = mysqli_query($conn, $query);\n?>Was passiert, wenn Sie in das Feld username admin' -- eingeben? Die Abfrage wird zu:
SELECT * FROM users WHERE username = 'admin' --' AND password = ''Der doppelte Bindestrich -- kommentiert den Rest der Abfrage aus. Voilà – der Angreifer loggt sich als Admin ohne Passwort ein. Und wenn Sie '; DROP TABLE users; -- eingeben? Tschüss, Benutzer.
Rettungsring: Prepared Statements
\n\nDer beste Weg, sich vor SQL-Injection zu schützen, ist die Verwendung von Prepared Statements über PDO oder MySQLi. Sie trennen die Logik der Abfrage von den Daten, sodass bösartiger Code niemals ausgeführt wird.
\n\nSo sieht sicherer Code mit PDO aus:
\n\n<?php\n// SICHER! Wir verwenden Prepared Statements\n$username = $_POST['username'];\n$password = $_POST['password'];\n\n$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");\n$stmt->execute(['username' => $username, 'password' => $password]);\n$user = $stmt->fetch();\n?>Selbst wenn der Angreifer nun admin' OR 1=1 -- übergibt, behandelt PDO dies als normale Zeichenfolge und nicht als Teil eines SQL-Befehls. Die Datenbank sagt: „Suche nach einem Benutzer mit diesem seltsamen Namen." Und findet keinen.
Warum PDO und nicht mysql_*?
\n\n- \n
- Sicherheit standardmäßig: PDO maskiert Daten automatisch. \n
- Flexibilität: Unterstützt verschiedene DBMS (MySQL, PostgreSQL, SQLite). \n
- Benannte Platzhalter: Der Code wird lesbar und wartbar. \n
- Objektorientierter Ansatz: Moderner Programmierstil. \n
Die mysql_*-Funktionen wurden aus PHP 7.0 entfernt, und das ist gut so. Wenn Sie immer noch mysqli_real_escape_string verwenden – das ist besser als nichts, aber PDO ist dennoch zuverlässiger.
XSS-Angriffe: Wenn Code sich in Kommentaren versteckt
\n\nCross-Site-Scripting (XSS) ist das Einschleusen von JavaScript-Code auf eine Seite über Benutzereingaben. Stellen Sie sich vor: Ein Benutzer hinterlässt einen Kommentar, schreibt aber statt Text:
\n\n<script>alert('Ihre Website wurde gehackt!');</script>Wenn Sie dies unverarbeitet ausgeben, sieht jeder Besucher ein Popup-Fenster. Und wenn statt alert Code steht, der Cookies stiehlt oder auf eine Phishing-Seite weiterleitet?
Arten von XSS-Angriffen
\n\n- \n
- Reflected (reflektiert): Der bösartige Co
