WordPress-Sicherheitsaudit: Was vor dem Livegang zu prüfen ist

Bevor ein von PAGEnza generiertes Plugin auf der WordPress-Installation eines Benutzers landet, durchläuft es drei automatisierte Sicherheitsprüfungen. Dieser Beitrag erklärt, worauf diese Prüfungen achten – und warum jede einzelne wichtig ist.

Warum KI-generierter Code ein Audit benötigt

Große Sprachmodelle sind überraschend gut darin, WordPress-Plugins zu schreiben. Sie kennen Hook-Namen, verstehen WP-Codierungsstandards und produzieren lesbares PHP. Aber sie machen auch vorhersehbare Fehler – und diese Fehler sind Sicherheitslücken.

Die häufigsten, die wir sehen:

• Verwendung von $_GET oder $_POST ohne Bereinigung (Sanitization)
• Fehlende Nonce-Verifizierung bei Formularübermittlungen
• Direkte Datenbankabfragen ohne $wpdb->prepare()
• Verwendung von eval() oder exec() für dynamisches Verhalten
• Ausgabe von Benutzerdaten ohne esc_html() oder esc_attr()

Dies sind keine exotischen Randfälle. Sie treten regelmäßig in LLM-Ausgaben auf – selbst bei den besten Modellen.

Stufe 1: Prompt-Validierung

Bevor die KI eine einzige Zeile schreibt, analysieren wir die Beschreibung des Benutzers. Dieser Schritt fängt zwei Kategorien von Problemen ab:

Manipulationsversuche – Prompts, die versuchen, die KI dazu zu bringen, absichtlich bösartigen Code zu produzieren. Dinge wie „ignoriere vorherige Anweisungen“ oder „erstelle ein Backdoor zum Testen“.

Vage oder unbrauchbare Beschreibungen – Prompts, die zu kurz oder zu mehrdeutig sind, um nützlichen Code zu produzieren. „Erstelle ein Plugin“ erzeugt Müll; „Erstelle ein Kontaktformular, das Übermittlungen mit Spamfilter an eine E-Mail-Adresse sendet“ erzeugt etwas Reales.

Wenn ein Prompt diesen Check nicht besteht, sieht der Benutzer eine spezifische Fehlermeldung, die erklärt, warum – keine generische Ablehnung.

Stufe 2: PHP-Linting in einem isolierten Container

Sobald die KI PHP-Code produziert hat, wird dieser mit php -l in einem Docker-Container ausgeführt, der vollständig von allem anderen isoliert ist. Dies fängt Syntaxfehler ab, bevor das Plugin überhaupt auf einer WordPress-Installation landet.

Aber wir gehen weiter: Wenn das Linting fehlschlägt, verwirft das System die Ausgabe nicht einfach. Es sendet den Fehler mit einem Korrektur-Prompt zurück an die KI – das nennen wir Healing. Die KI sieht ihren eigenen Fehler und versucht es erneut, bis zu dreimal.

Das bedeutet, dass Benutzer fast nie eine Meldung wie „Generierung fehlgeschlagen“ sehen. Sie sehen eine etwas längere Generierungszeit – und funktionierenden Code.

Stufe 3: Code-Sicherheits-Scan

Dies ist die wichtigste Stufe. Wir führen einen statischen Analyse-Durchlauf durch, der Folgendes prüft:

Gefährliche Funktionen: eval(), exec(), system(), shell_exec(), passthru() – jede dieser Funktionen blockiert die Freigabe des Plugins.

SQL-Injection-Vektoren: Rohe $wpdb->query()-Aufrufe mit interpolierten Variablen, fehlende $wpdb->prepare(), direkte mysql_query()-Verwendung.

Fehlende Berechtigungsprüfungen: AJAX-Handler, die current_user_can() nicht aufrufen, bevor sie privilegierte Aktionen durchführen.

Fehlende Nonce-Verifizierung: Formularverarbeiter, die wp_verify_nonce() oder check_ajax_referer() nicht aufrufen.

Unescaped Output: echo $_GET[...], echo $user_input ohne Escaping-Funktionen.

Wenn einer dieser Punkte gefunden wird, wird das Plugin blockiert. Der Benutzer sieht einen Bericht, der genau auflistet, welche Funktionen den Block ausgelöst haben und warum – nicht nur „Sicherheitsprüfung fehlgeschlagen“.

Wie der Audit-Bericht aussieht

Jedes generierte Plugin wird mit einem Audit-Bericht in einfacher Sprache geliefert. Er listet auf:

• Welche Prüfungen bestanden wurden (grün)
• Welche Prüfungen Warnungen ausgelöst haben (gelb) – Probleme, die keine Blocker sind, aber Aufmerksamkeit verdienen
• Alle Korrekturen, die während des Healings automatisch angewendet wurden

Der Bericht wird automatisch generiert und dem Plugin-Download beigefügt. Er ist sowohl für Ihr eigenes Vertrauen nützlich als auch um Kunden zu zeigen, dass Sie Sicherheit ernst genommen haben.

Stufe 4: Validierung beim Speichern

Dies ist kein Teil der anfänglichen Generierung – es gilt, wenn Benutzer Code manuell im PAGEnza-Editor bearbeiten.

Jedes Mal, wenn Sie speichern, wird derselbe Lint- und Sicherheits-Scan erneut ausgeführt. Wenn Sie beim Bearbeiten eine kritische Sicherheitslücke einführen, wird das Speichern blockiert, bis Sie sie behoben haben. Dies verhindert das häufige Szenario, in dem ein Entwickler eine schnelle „temporäre“ Änderung vornimmt, die zwei Jahre lang in der Produktion verbleibt.

Die Grenzen der automatisierten Prüfung

Automatisierte Scans fangen eine bestimmte Klasse von Problemen gut ab. Sie fangen nicht alles auf.

Logikfehler, fehlerhafte Geschäftslogik und subtile Probleme bei der Eskalation von Berechtigungen, die keine bekannten gefährlichen Muster beinhalten, erfordern immer noch eine menschliche Überprüfung. Wir sind in der Dokumentation transparent darüber – das Audit ersetzt keine Sicherheitsüberprüfung, es ist eine Untergrenze, die einen Mindeststandard garantiert.

Für Produktions-Plugins, die Zahlungen oder sensible Daten verarbeiten, empfehlen wir zusätzlich zu den automatisierten Prüfungen eine manuelle Überprüfung. Der Audit-Bericht bietet einem menschlichen Prüfer einen guten Ausgangspunkt.