Injection, XSS und CSRF verstehen und verhindern

Begriffe vorab

• SQL-Injection: Eingaben verändern eine Datenbankabfrage, weil sie als Teil des SQL-Codes behandelt werden.
• Prepared Statement: Abfrage mit Platzhaltern; Code und Daten werden getrennt übergeben.
• XSS: Cross-Site Scripting: Fremder Skriptcode wird in einer Seite ausgeführt.
• Ausgabekodierung: Umwandlung von Daten, damit sie als Text und nicht als Code dargestellt werden.
• CSRF: Cross-Site Request Forgery: Eine fremde Seite löst im Namen einer angemeldeten Person eine Aktion aus.
• SameSite: Cookie-Attribut, das steuert, wann Cookies bei Anfragen von anderen Seiten mitgesendet werden.

Das gemeinsame Muster

Bei Injection und XSS wird Eingabe zu Code: Ein Interpreter (Datenbank, Browser) kann Daten und Befehle nicht unterscheiden. Bei CSRF wird eine Anfrage ausgelöst, die der Server für beabsichtigt hält. Die Gegenmittel setzen jeweils an der Trennung von Daten und Code bzw. am Nachweis der Absicht an.

SQL-Injection

Der OWASP-Leitfaden nennt Prepared Statements mit parametrisierten Abfragen als erste und wichtigste Verteidigung. Der Abfragecode wird zuerst festgelegt, die Werte werden danach getrennt übergeben, sodass die Datenbank unabhängig von der Eingabe zwischen Code und Daten unterscheiden kann.

// Unsicher: Eingabe landet im SQL-Text
$wpdb->query( "SELECT * FROM {$wpdb->users} WHERE user_login = '$name'" );

// Sicher: Platzhalter, Wert wird getrennt übergeben
$wpdb->get_results(
    $wpdb->prepare( "SELECT * FROM {$wpdb->users} WHERE user_login = %s", $name )
);

Wird der Wert tom' or '1'='1 übergeben, sucht die abgesicherte Variante nach einem Nutzer mit genau diesem Namen, statt die Bedingung zu verändern.

Cross-Site-Scripting

Hauptschutz ist die Ausgabekodierung passend zum Kontext (HTML, Attribut, JavaScript, CSS, URL). Eine Content Security Policy begrenzt zusätzlich, welche Skripte laden dürfen, sollte aber mit anderen Maßnahmen kombiniert werden, weil sie allein schwer korrekt einzurichten und umgehbar sein kann.

CSRF

Wirksam sind CSRF-Tokens (ohne gültiges Token kann ein Angreifer keine gültige Anfrage erzeugen). Das Cookie-Attribut SameSite hilft zusätzlich: Mit „Lax“ wird das Cookie beim Senden eines Formulars von einer fremden Seite nicht mitgeschickt. OWASP rät, SameSite als zusätzliche Schicht zu verstehen und mit Tokens zu kombinieren.

Merksatz

Eingaben früh prüfen, Ausgaben spät kodieren, Anfragen mit Nachweis der Absicht absichern.

Entscheidend ist der Kontext: Dieselbe Zeichenfolge muss in HTML anders kodiert werden als in einer URL oder in JavaScript.

Zum Selbermachen

1. Schreibe eine Abfrage mit Platzhalter für eine Suche nach Titel und prüfe sie mit einem Hochkomma im Suchbegriff (nur in der Testumgebung).
2. Prüfe in den Entwicklerwerkzeugen deines Browsers, welche SameSite-Werte deine Sitzungscookies haben.

Verwandte Themen

WordPress → die nächste Lektion zeigt die passenden WordPress-Funktionen (Escaping, Nonces). Agentische KI → „Agenten: Sicherheit“ (Prompt Injection, Lethal Trifecta) und „KI-Sicherheit & Alignment“ zeigen, wie dieselben Grundideen auf KI-Systeme übertragen werden. Prompt Injection ist strukturell verwandt: Anweisungen und Daten werden vermischt.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Prepared Statements als erste Verteidigung gegen SQL-Injection, kontextabhängige Ausgabekodierung, CSP nur in Kombination mit anderen Maßnahmen sowie CSRF-Tokens und SameSite-Lax wurden gegen die OWASP Cheat Sheet Series geprüft. Nicht einzeln belegt: der Codeausschnitt ($wpdb->prepare, konstruiert und nicht ausgeführt), die Parallele zur Prompt Injection (Einordnung in eigenen Worten).

Quellen

• OWASP Cheat Sheet Series – „SQL Injection Prevention“ und „Query Parameterization“
• OWASP Cheat Sheet Series – „Cross Site Scripting Prevention“
• OWASP Cheat Sheet Series – „Cross-Site Request Forgery Prevention“