Security: Webanwendungen

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“

WordPress-Sicherheit: validieren, bereinigen, kodieren

Begriffe vorab

• Validierung: Prüfen, ob eine Eingabe dem Erwarteten entspricht, und sie sonst ablehnen.
• Sanitization: Eingaben bereinigen, bevor sie gespeichert oder weiterverwendet werden.
• Escaping: Ausgaben unmittelbar vor der Darstellung kodieren.
• Nonce: Einmalig gültiger Wert zum Nachweis, dass eine Anfrage beabsichtigt ist.
• Capability: Eine Berechtigung, die vor sensiblen Aktionen geprüft wird.

Die Grundregel

Das WordPress-Entwicklerhandbuch fasst die Datenbehandlung so zusammen: Daten aus nicht vertrauenswürdigen Quellen werden so früh wie möglich validiert und bereinigt und so spät wie möglich kodiert. Validierung lehnt Unpassendes ab, Bereinigung schützt Speicherung und Logik, Escaping schützt die Ausgabe – auch dann, wenn die Daten vorher bereinigt wurden.

Die vier Bausteine einer sicheren Aktion

1. Berechtigung: Prüfe mit current_user_can(), ob die Person die Aktion ausführen darf.
2. Absicht: Prüfe einen Nonce, damit keine fremde Seite die Aktion auslösen kann.
3. Eingaben: validiere und bereinige (wp_unslash und passende sanitize_*-Funktionen).
4. Ausgabe: kodiere mit passenden esc_*-Funktionen.

function mein_plugin_speichern() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Keine Berechtigung.' );
    }
    check_admin_referer( 'mein_plugin_speichern' );   // Nonce prüfen

    $titel = isset( $_POST['titel'] )
        ? sanitize_text_field( wp_unslash( $_POST['titel'] ) )
        : '';
    update_option( 'mein_plugin_titel', $titel );
}

// Ausgabe
echo esc_html( get_option( 'mein_plugin_titel' ) );

Was ein Nonce nicht ist

Ein Nonce weist nach, dass eine Anfrage aus deiner Oberfläche stammt; er ersetzt keine Berechtigungsprüfung. Beide Prüfungen gehören zusammen – das ist wieder das Prinzip der gestuften Absicherung aus der Lektion über Entwurfsprinzipien.

Typische Fehler

• Prüfung nur im Browser (JavaScript) statt auf dem Server.
• Ausgabe ohne esc_*, weil „die Daten ja schon bereinigt sind“.
• Datenbankabfragen mit zusammengesetzten Zeichenketten statt $wpdb->prepare().
• Berechtigungsprüfung vergessen, weil der Link nur Administratoren angezeigt wird.

Prüfe bei jedem Formular- oder AJAX-Handler zuerst die Berechtigung, dann den Nonce, dann die Eingaben.

Zum Selbermachen

1. Gehe ein eigenes Plugin durch und markiere jeden Handler, dem eine der vier Prüfungen fehlt.
2. Ersetze eine zusammengesetzte SQL-Abfrage durch eine mit Platzhaltern.

Verwandte Themen

WordPress → „WordPress-Plugin-Deepdive“ behandelt Hooks, Einstellungen und Sicherheit im Zusammenhang. Webanwendungen → „Injection, XSS und CSRF“ erklärt die Angriffe, gegen die diese Funktionen schützen.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Die Grundregeln (früh validieren und bereinigen, spät kodieren), Nonces für Formulare und Berechtigungsprüfungen mit current_user_can wurden gegen die WordPress-Dokumentation (Developer Resources, Learn WordPress) geprüft. Nicht einzeln belegt: das konkrete Codebeispiel (konstruiert und nicht in einer WordPress-Installation ausgeführt) und die Liste typischer Fehler (Einordnung in eigenen Worten).

Quellen

• WordPress Developer Resources – „Security“ (developer.wordpress.org/themes/advanced-topics/security)
• Learn WordPress – „Introduction to securely developing plugins“
• WordPress Plugin Handbook – „Common issues“