WordPress Plugins Auditieren

#Einführung: Das KI-Versprechen vs. WordPress-Realität

Die Verwendung von Large Language Models (LLMs) wie GPT-4, Claude 3.5 Sonnet oder Gemini Pro zum Schreiben von WordPress-Plugin-Code ist für Entwickler und Website-Betreiber gleichermaßen zur Routine geworden. Das Versprechen ist verlockend: Beschreiben Sie die gewünschte Funktionalität in einfachem Deutsch, und die KI generiert in Sekundenschnelle eine gebrauchsfertige PHP-Datei.

Das Problem ist jedoch, dass Sprachmodelle zwar hervorragend in Syntax und Struktur sind, ihnen aber der betriebliche Kontext und ein echtes Verständnis der Sicherheitsprinzipien innerhalb des WordPress-Ökosystems fehlen. Sie wurden mit riesigen Mengen an öffentlichem Code trainiert und erben daher Millionen von veralteten, unsicheren und schlecht geschriebenen Plugins, die in den letzten zwei Jahrzehnten veröffentlicht wurden. Infolgedessen gibt die KI oft Code aus, der syntaktisch einwandfrei und funktional ist, unter der Haube jedoch kritische Sicherheitslücken aufweist.

Als WordPress-Entwickler müssen wir gegenüber jedem von einer KI geschriebenen Code eine strikte “Zero Trust”-Haltung einnehmen. Dieser Leitfaden beschreibt die fünf häufigsten Sicherheitsfehler-Muster, die wir bei Audits von KI-generiertem Plugin-Code beobachten, und veranschaulicht sie anhand von anfälligen PHP-Snippets neben sicheren, produktionsreifen Refactorings, die den WordPress-Codierungsstandards (WPCS) entsprechen.

#1. Missbrauch von is_admin() zur Zugriffskontrolle

Der vielleicht häufigste logische Fehler, den KI bei dem Versuch macht, einen Endpunkt zu sichern, ist der Rückgriff auf die Funktion is_admin(), um den Zugriff auf Administratoren zu beschränken.

#Warum es fehlschlägt

Trotz ihres Namens überprüft is_admin() nicht, ob der aktuell angemeldete Benutzer ein Administrator ist. Sie prüft lediglich, ob die aktuelle Anfrage für eine Administrationsseite bestimmt ist (z. B. jede URL, die mit /wp-admin/ beginnt).

Jede AJAX-Anfrage, die an /wp-admin/admin-ajax.php gesendet wird – unabhängig davon, ob sie von einem Administrator, einem angemeldeten Abonnenten mit minimalen Rechten oder einem nicht authentifizierten anonymen Besucher initiiert wurde – führt dazu, dass is_admin() den Wert true zurückgibt.

#Anfälliger KI-generierter Code:

// Ein von der KI generierter Hook zum Speichern von Plugin-Einstellungen
add_action( 'admin_init', 'ai_save_plugin_settings' );
function ai_save_plugin_settings() {
    // Die KI nimmt fälschlicherweise an, dass dies den Zugriff auf Administratoren beschränkt
    if ( is_admin() ) {
        if ( isset( $_POST['my_plugin_option'] ) ) {
            update_option( 'my_plugin_option', $_POST['my_plugin_option'] );
        }
    }
}

#Sicherer Code:

Um die tatsächlichen Berechtigungen des angemeldeten Benutzers zu überprüfen, müssen Sie die Funktion current_user_can() verwenden und eine spezifische Benutzerberechtigung anstelle eines Rollennamens übergeben, z. B. manage_options.

add_action( 'admin_init', 'secure_save_plugin_settings' );
function secure_save_plugin_settings() {
    // 1. Überprüfen Sie die tatsächlichen Fähigkeiten des aktuellen Benutzers
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( esc_html__( 'Sie haben keine Berechtigung, diese Aktion auszuführen.', 'secure-plugin' ) );
    }

    if ( isset( $_POST['my_plugin_option'] ) ) {
        // Eingabebereinigung anwenden (siehe Abschnitt 4)
        $sanitized_value = sanitize_text_field( wp_unslash( $_POST['my_plugin_option'] ) );
        update_option( 'my_plugin_option', $sanitized_value );
    }
}

#2. Vollständiges Weglassen der Nonce-Verifizierung (CSRF)

Cross-Site Request Forgery (CSRF)-Angriffe verleiten den Browser eines authentifizierten Benutzers (z. B. eines Administrators) dazu, unerwünschte Aktionen auf einer Website auszuführen, auf der er gerade angemeldet ist. WordPress verwendet kryptografische Token namens Nonces, um vor CSRF zu schützen.

KI-Generatoren lassen die Erstellung und Überprüfung von Nonces in Admin-Formularen, AJAX-Handlern und benutzerdefinierten REST-API-Endpunkten häufig weg. Dies geschieht, weil die Implementierung von Nonces die Koordinierung der Frontend-Rendering-Ebene (das HTML-Formular mit dem Nonce-Feld) mit dem Backend-Verarbeitungs-Controller erfordert, was für LLMs über verschiedene Codegenerierungen hinweg schwer abzustimmen ist.

#Anfälliger KI-generierter AJAX-Handler:

// KI-generierte AJAX-Endpunktregistrierung
add_action( 'wp_ajax_ai_delete_post', 'ai_delete_post_handler' );
function ai_delete_post_handler() {
    // KI prüft Berechtigungen, ignoriert aber CSRF vollständig (keine Nonce-Prüfung)
    if ( ! current_user_can( 'delete_posts' ) ) {
        wp_send_json_error( 'Nicht autorisiert.' );
    }

    $post_id = intval( $_POST['post_id'] );
    wp_delete_post( $post_id );
    wp_send_json_success( 'Beitrag gelöscht.' );
}

#Sicherer Code:

Das Ausgabeformular muss ein Nonce-Feld mit wp_nonce_field() ausgeben, und der empfangende PHP-Controller muss das Token mit check_ajax_referer() oder wp_verify_nonce() überprüfen.

// Im Formular-Rendering-File oder Javascript-Payload:
// wp_nonce_field( 'delete_post_action', 'my_nonce_field' );

// Registrierung des gesicherten AJAX-Handlers
add_action( 'wp_ajax_secure_delete_post', 'secure_delete_post_handler' );
function secure_delete_post_handler() {
    // 1. CSRF-Token frühzeitig verifizieren
    check_ajax_referer( 'delete_post_action', 'my_nonce_field' );

    // 2. Benutzerberechtigungen verifizieren
    if ( ! current_user_can( 'delete_posts' ) ) {
        wp_send_json_error( 'Nicht autorisiert.' );
    }

    // 3. Eingabevariablen validieren und typisieren
    if ( ! isset( $_POST['post_id'] ) ) {
         wp_send_json_error( 'Fehlende Beitrags-ID.' );
    }

    $post_id = absint( $_POST['post_id'] );
    
    if ( wp_delete_post( $post_id ) ) {
        wp_send_json_success( 'Beitrag erfolgreich gelöscht.' );
    } else {
        wp_send_json_error( 'Fehler beim Löschen des Beitrags.' );
    }
}

#3. SQL-Injection-Schwachstellen in $wpdb-Abfragen

Wenn ein Plugin direkt mit der Datenbank interagiert, anstatt den nativen WP_Query-Wrapper zu verwenden, nutzt es das globale Objekt $wpdb. Leider erstellen LLMs häufig rohe SQL-Zeichenfolgen unter direkter Verkettung von benutzerdefinierten Variablen ($_POST, $_GET), anstatt die Abfrage zu parametrisieren.

#Warum es gefährlich ist

Das direkte Verketten von rohen Variablen in Datenbankabfragen ermöglicht es einem Angreifer, die Abfragestruktur zu manipulieren. Dies kann zu unbefugtem Datenabruf (wie gehashten Benutzerkennwörtern), Datenbanklöschungen oder der Eskalation von Administratorrechten führen.

#Anfällige KI-generierte Abfrage:

// Von KI generierte Benutzersuchfunktion
function ai_find_users_by_city( $city_name ) {
    global $wpdb;
    // Kritischer Fehler: direkte Verkettung der Abfragevariablen
    $query = "SELECT * FROM {$wpdb->prefix}custom_users WHERE city = '" . $city_name . "'";
    return $wpdb->get_results( $query );
}

#Sicherer Code:

Es sollten niemals rohe Variablen direkt in SQL-Zeichenfolgen geschrieben werden. Verwenden Sie stattdessen die Methode $wpdb->prepare(), die als parametrisierte Abfrage-Engine fungiert und Werte unter Verwendung von Formatbezeichnern (%s für Zeichenfolgen, %d für Ganzzahlen, %f für Fließkommazahlen) typisiert und maskiert.

function secure_find_users_by_city( $city_name ) {
    global $wpdb;

    // 1. Verwenden Sie prepare() mit Formatbezeichnern
    $query = $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}custom_users WHERE city = %s",
        $city_name
    );

    return $wpdb->get_results( $query );
}

Hinweis: Wenn die Variable $city_name direkt aus einer Benutzereingabe stammt, muss sie vor der Datenbankverarbeitung dennoch mit sanitize_text_field() bereinigt werden.

#4. Fehlende Eingabebereinigung und Ausgabe-Escaping (XSS)

Cross-Site Scripting (XSS) gehört zu den häufigsten Schwachstellen in WordPress-Plugins. Es ermöglicht das Speichern oder dynamische Spiegeln von böswilligem JavaScript-Code in der Datenbank, der dann im Browser ahnungsloser Besucher ausgeführt wird.

KI-Modelle verwechseln häufig Bereinigung (Bereinigen von Daten beim Empfang) mit Escaping (Sichern von Daten bei der Ausgabe). Selbst wenn die KI Eingaben bereinigt, zeigt sie Variablen in Vorlagen oft an, ohne sie vorher zu maskieren, was die Website für Stored XSS öffnet.

#Anfällige KI-generierte Darstellung:

// Von der KI geschriebene Feedback-Anzeigeschleife
function ai_display_user_feedback() {
    $feedbacks = get_option( 'ai_user_feedback_list', [] );
    
    echo '<div class="feedback-list">';
    foreach ( $feedbacks as $feedback ) {
        // Kritischer Fehler: Rohausgabe ohne Escaping
        echo '<p class="feedback-item">' . $feedback['user_comment'] . '</p>';
    }
    echo '</div>';
}

#Sicherer Code:

Befolgen Sie die grundlegende WordPress-Regel: Sanitize Early, Escape Late (Eingabevariablen sofort bereinigen; Ausgabe unmittelbar vor der Ausgabe an den Browser maskieren).

Wählen Sie die richtige Escaping-Funktion für den Kontext:

• esc_html() – für Standard-Textknoten innerhalb von HTML-Elementen.
• esc_attr() – für die Ausgabe innerhalb von HTML-Attributwerten.
• esc_url() – für die Ausgabe von Links.
• wp_kses() – wenn Sie bestimmte, sichere HTML-Tags zulassen müssen (wie strong, anchors).

function secure_display_user_feedback() {
    $feedbacks = get_option( 'secure_user_feedback_list', [] );
    
    echo '<div class="feedback-list">';
    foreach ( $feedbacks as $feedback ) {
        $comment = isset( $feedback['user_comment'] ) ? $feedback['user_comment'] : '';
        
        // 1. Ausgabe kontextabhängig unmittelbar vor dem Rendern maskieren
        echo '<p class="feedback-item">';
        echo esc_html( $comment );
        echo '</p>';
    }
    echo '</div>';
}

#5. Gefährliche Datei-Upload-Implementierung (Arbitrary File Upload)

Benutzern das Hochladen von Dateien zu erlauben (z. B. Kontaktformulare mit Anhängen oder Avatar-Uploads), gehört zu den risikoreichsten Operationen auf einer Website. Ein Fehler an dieser Stelle ermöglicht es Angreifern, eine .php-Datei hochzuladen, was zu Remote Code Execution (RCE) und einer vollständigen Serverkompromittierung führt.

KI-generierte Datei-Handler verlassen sich häufig auf native PHP-Befehle wie move_uploaded_file() in Kombination mit schwachen Dateierweiterungsprüfungen (wie einfachem String-Matching), die für Angreifer leicht zu umgehen sind (z. B. das Hochladen von Dateien mit dem Namen malicious.php.jpg oder die Verwendung alternativer Erweiterungen wie .phtml).

#Anfälliger KI-generierter Datei-Upload:

// Von KI geschriebener Upload-Handler
function ai_handle_avatar_upload() {
    if ( isset( $_FILES['avatar'] ) ) {
        $file_name = $_FILES['avatar']['name'];
        $ext = pathinfo( $file_name, PATHINFO_EXTENSION );
        
        // KI nimmt an, dass diese Erweiterungsprüfung sicher ist
        if ( in_array( $ext, ['jpg', 'jpeg', 'png'] ) ) {
            $target = wp_upload_dir()['path'] . '/' . $file_name;
            move_uploaded_file( $_FILES['avatar']['tmp_name'], $target );
        }
    }
}

#Sicherer Code:

Verwenden Sie niemals natives PHP-move_uploaded_file() innerhalb von WordPress. Verwenden Sie stattdessen die Core-Funktion wp_handle_upload(). Sie führt eine robuste MIME-Typ-Prüfung durch (überprüft die tatsächliche Dateisignatur, nicht nur den Namen), validiert den Upload-Status und integriert sich in das WordPress-Berechtigungssystem.

function secure_handle_avatar_upload() {
    // 1. Validieren Sie das CSRF-Token
    if ( ! isset( $_POST['avatar_upload_nonce'] ) || ! wp_verify_nonce( $_POST['avatar_upload_nonce'], 'upload_avatar_action' ) ) {
        wp_die( esc_html__( 'Ungültiges Sicherheits-Token.', 'secure-plugin' ) );
    }

    // 2. Capability-Prüfungen verifizieren
    if ( ! current_user_can( 'upload_files' ) ) {
        wp_die( esc_html__( 'Sie haben keine Berechtigung, Dateien hochzuladen.', 'secure-plugin' ) );
    }

    if ( isset( $_FILES['avatar'] ) ) {
        if ( ! function_exists( 'wp_handle_upload' ) ) {
            require_once ABSPATH . 'wp-admin/includes/file.php';
        }

        // 3. Erlaubte MIME-Typen erzwingen
        $allowed_mimes = [
            'jpg|jpeg' => 'image/jpeg',
            'png'      => 'image/png'
        ];

        $upload_overrides = [
            'test_form' => false,
            'mimes'     => $allowed_mimes
        ];

        // 4. Upload-Verarbeitung an Core-Funktion delegieren
        $movefile = wp_handle_upload( $_FILES['avatar'], $upload_overrides );

        if ( $movefile && ! isset( $movefile['error'] ) ) {
            $avatar_url = $movefile['url'];
            update_user_meta( get_current_user_id(), 'user_avatar', $avatar_url );
        } else {
            // Fehler sicher protokollieren
            error_log( 'Fehler beim Hochladen der Datei: ' . $movefile['error'] );
        }
    }
}

#Audit-Methodik: Implementierung von Zero Trust für KI-Code

Um von KI generierten Code sicher bereitzustellen, muss Ihr Engineering-Team einen systematischen Überprüfungsprozess einrichten. Implementieren Sie diese drei Schritte, bevor Sie generierte Assets in die Produktion überführen:

#Schritt 1: Statische Analyse automatisieren (PHPCS)

Konfigurieren Sie die WordPress Coding Standards (WPCS) für das PHP_CodeSniffer-Tool. Es scannt Dateien und kennzeichnet fehlende Bereinigungen, weggelassene Nonces und unescapte Variablen automatisch.

# Scannen einer generierten Plugin-Datei mit WordPress-Standards
vendor/bin/phpcs --standard=WordPress-Extra path/to/generated-plugin.php

#Schritt 2: Manuellen Code-Review durchführen

Überprüfen Sie jeden Handler, der HTTP-Abfragen, Datenbanktransaktionen, AJAX-Aufrufe oder REST-API-Verbindungen ausführt, anhand des folgenden Flussdiagramms:

graph TD
    A["KI-geschriebenen Plugin-Code empfangen"] --> B{"Akzeptiert er Benutzereingaben?"}
    B -- Ja --> C["Auf Nonce & Capability-Prüfungen prüfen"]
    B -- No --> D{"Modifiziert er die Datenbank?"}
    
    C --> C1["check_ajax_referer() / CSRF-Validierung implementieren"]
    C --> C2["current_user_can() Berechtigungsprüfung implementieren"]
    C1 --> D
    C2 --> D
    
    D -- Yes --> E["Prüfen auf $wpdb->prepare() Nutzung"]
    D -- No --> F{"Gibt er an den Browser aus?"}
    
    E --> E1["Parametrisierte SQL-Variablen implementieren"]
    E1 --> F
    
    F -- Yes --> G["esc_html(), esc_attr(), oder esc_url() verifizieren"]
    F -- No --> H["Mit Integrationstests fortfahren"]
    
    G --> G1["Kontextbezogenes Ausgabe-Escaping implementieren"]
    G1 --> H

#Schritt 3: Tests mit geringen Rechten ausführen

Überprüfen Sie die Zugriffsgrenzen des Codes. Melden Sie sich als Benutzer mit der Rolle “Abonnent” an und lösen Sie die REST- oder AJAX-Aktionen des Plugins direkt über curl oder Postman aus. Wenn der Server Änderungen ausführt oder Datenbankdaten preisgibt, fehlen die Berechtigungsebenen.

#Zusammenfassung und Empfehlungen

Künstliche Intelligenz ist ein mächtiger Beschleuniger für das Schreiben von Code, kann aber keine technische Verantwortung übernehmen. Behandeln Sie den gesamten von einer KI geschriebenen Code so, als stammte er von einem unerfahrenen Praktikanten.

Stellen Sie sicher, dass Sie robuste Capability-Prüfungen (current_user_can()), CSRF-Verifizierungen (wp_verify_nonce()), Datenbankparametrisierungen ($wpdb->prepare()), Eingabebereinigung und spätes Ausgabe-Escaping implementieren. Durch die Kombination dieser Kernpraktiken mit statischen Analysetools können Sie WordPress-Code schneller schreiben und gleichzeitig eine absolut sichere Anwendung gewährleisten.