Modul C · Qualität & Sicherheit · Lektion C2

Sicherheitsgrundlagen für PHP-Anwendungen: die wichtigsten Angriffe und Gegenmittel

Aktualisiert am 24.09.20263 Min. Lesezeit

Das Grundprinzip: Daten sind nie vertrauenswürdig

Alles, was von außen kommt, kann manipuliert sein: Formularfelder, URL-Parameter, Cookies, HTTP-Header, hochgeladene Dateien – und auch Daten aus der eigenen Datenbank, wenn sie ursprünglich von Nutzern stammen. Daraus folgen zwei Regeln: Eingaben prüfen und Ausgaben passend zum Zielort maskieren.

SQL-Injection

Wird eine Eingabe direkt in eine SQL-Abfrage eingebaut, kann ein Angreifer die Abfrage verändern – Daten auslesen, ändern oder löschen. So sieht der Fehler aus:

<?php// Unsicher: niemals so!class="va">$sql = "SELECT * FROM nutzer WHERE email = '" . class="va">$_POST['email'] . "'";

Das Gegenmittel sind Prepared Statements. Abfrage und Daten werden getrennt an die Datenbank geschickt, sodass Eingaben nie als SQL-Befehl interpretiert werden können:

<?phpclass="va">$stmt = class="va">$pdo->prepare('SELECT id, name FROM nutzer WHERE email = :email');class="va">$stmt->execute(['email' => class="va">$_POST['email'] ?? '']);class="va">$nutzer = class="va">$stmt->fetch();

Diese Schreibweise ist nicht umständlicher, nur anders. Gewöhne sie dir von der ersten Übung an.

Cross-Site-Scripting (XSS)

Gibt eine Seite Eingaben ungefiltert als HTML aus, kann ein Angreifer eigenes JavaScript einschleusen – das dann im Browser anderer Besucher läuft, etwa um Sitzungen zu übernehmen. Die Abwehr: Jede Ausgabe in HTML wird maskiert.

<?phpfunction e(string class="va">$text): string{    return htmlspecialchars(class="va">$text, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');}echo '<p>Hallo, ' . e(class="va">$name) . '</p>';

Template-Engines wie Twig oder Blade maskieren standardmäßig automatisch. Das ist einer der stillen Vorteile moderner Frameworks.

Cross-Site Request Forgery (CSRF)

Bei CSRF bringt eine fremde Seite den Browser eines angemeldeten Nutzers dazu, eine Aktion in deiner Anwendung auszulösen – etwa eine E-Mail-Adresse zu ändern. Das Gegenmittel ist ein zufälliges Token, das in jedem Formular mitgeschickt und auf dem Server geprüft wird:

<?phpsession_start();class="va">$_SESSION['csrf'] ??= bin2hex(random_bytes(32));// beim Absenden:if (!hash_equals(class="va">$_SESSION['csrf'], class="va">$_POST['csrf'] ?? '')) {    http_response_code(403);    exit('Ungültige Anfrage');}

Zusätzlich hilft es, Session-Cookies mit dem Attribut SameSite=Lax oder Strict zu setzen.

Passwörter richtig speichern

Passwörter werden nie im Klartext gespeichert und auch nicht mit schnellen Prüfsummen wie md5() oder sha1(). Seit PHP 5.5 gibt es dafür zwei Funktionen, die alles Nötige erledigen – inklusive Salt und langsamem, dafür vorgesehenem Algorithmus:

<?phpclass="va">$hash = password_hash(class="va">$passwort, PASSWORD_DEFAULT);if (password_verify(class="va">$eingabe, class="va">$hash)) {    // angemeldet}

PASSWORD_DEFAULT wählt automatisch den aktuell empfohlenen Algorithmus. Mit password_needs_rehash() kannst du alte Hashes beim nächsten Login still erneuern.

Aktualität ist Sicherheit

Viele erfolgreiche Angriffe nutzen keine neue Lücke, sondern eine seit Langem bekannte, die nie geschlossen wurde. Eine PHP-Version ohne Sicherheitssupport, ein nicht aktualisiertes CMS-Plugin oder eine alte Bibliothek genügen. Wie du den Überblick behältst, zeigen PHP-Versionen und Support und der Befehl composer audit aus der Lektion über Composer.

Weiter lernen

Einen hervorragenden Überblick über die häufigsten Risiken bietet die OWASP Top Ten, eine regelmäßig aktualisierte Liste der Open Worldwide Application Security Project Foundation. Für Deutschland veröffentlicht das Bundesamt für Sicherheit in der Informationstechnik Empfehlungen, auch für den sicheren Betrieb von Webservern. Wie sich Verschlüsselung durch neue Rechnertypen verändern könnte, beschreibt Quantencomputing.