SQL-Injection

Fast jede dynamische Website, WordPress eingeschlossen, speichert ihre Inhalte in einer Datenbank, die per SQL abgefragt wird. Baut der Code eine Abfrage zusammen, indem er einen vom Besucher empfangenen Wert einfügt, vermischt er zwei Dinge, die getrennt bleiben sollten: Anweisungen und Daten. Der Angreifer nutzt das, um Anweisungen dort unterzubringen, wo Daten erwartet wurden. MITRE führt diese Schwäche als CWE-89.

So funktioniert eine SQL-Injection

Nimm Code, der einen Beitrag anhand seines Namens sucht und die Abfrage dafür von Hand zusammensetzt:

$sql = "SELECT * FROM articles WHERE name = '" . $_GET['name'] . "'";

Schickt der Besucher x' OR 'a'='a, schließt das Anführungszeichen die vom Entwickler vorgesehene Zeichenkette, und der Rest wird zu SQL. Die Bedingung ist immer wahr: Die Datenbank liefert die gesamte Tabelle. Mit anderen Payloads kann der Angreifer Daten aus anderen Tabellen auslesen, ändern oder löschen.

Was ein Angreifer erreichen kann

OWASP fasst die möglichen Folgen einer erfolgreichen Injection zusammen:

• sensible Daten lesen: E-Mail-Adressen, Bestellungen, Passwort-Hashes;
• Datensätze einfügen, ändern oder löschen, zum Beispiel einem Konto die Rolle Administrator geben, was sie zu einem Weg zur Rechteausweitung macht;
• die Authentifizierung umgehen;
• in manchen Fällen Dateien auf dem Server lesen oder Befehle an das Betriebssystem senden, bis hin zur Remote Code Execution.

Nicht jede Injection zeigt ihr Ergebnis auf dem Bildschirm an. Bei den sogenannten „blinden“ Varianten erschließt der Angreifer die Daten Stück für Stück aus Unterschieden in den Antworten oder Antwortzeiten. Das dauert länger, ist mit einem automatisierten Werkzeug aber genauso wirksam. Unter den seit 2020 in WooCommerce gefundenen Schwachstellen sind mehrere SQL-Injections, und die Warnung zu All-in-One WP Migration zeigt, dass eine solche Lücke abgeklopft wird, sobald sie bekannt ist.

In WordPress: $wpdb->prepare()

Funktionen auf hoher Ebene (WP_Query, get_posts(), update_option()…) bauen ihre Abfragen selbst. Sobald ein Plugin mit dem Objekt $wpdb eine eigene Abfrage schreibt, muss jeder variable Wert durch $wpdb->prepare() laufen. Die Platzhalter sind %s (Zeichenkette), %d (Ganzzahl), %f (Gleitkommazahl) und seit WordPress 6.2 %i für einen Tabellen- oder Spaltennamen.

$ids = $wpdb->get_col( $wpdb->prepare(
    "SELECT ID FROM {$wpdb->posts} WHERE post_author = %d AND post_status = %s",
    $author_id,
    'publish'
) );

• Setze keine Anführungszeichen um %s: Die Funktion ergänzt sie selbst.
• Für eine Suche mit LIKE übergibst du die vollständige Zeichenkette als Argument, nachdem du sie durch $wpdb->esc_like() geschickt hast.
• Kennungen vorher mit absint() umzuwandeln ist eine zusätzliche Absicherung, kein Ersatz für eine vorbereitete Abfrage.

So schützt du deine Website als Betreiber

• Spiel Sicherheitsupdates von Plugins zügig ein: Ihren Code wirst du nicht selbst reparieren.
• Gib dem Datenbankbenutzer nur die Rechte, die WordPress braucht, um den Schaden einer gekaperten Abfrage zu begrenzen.
• Schalte eine Web Application Firewall vor die Website: Ihre Regeln erkennen die bekanntesten Injection-Payloads und können eine Lücke abdecken, bis der Patch da ist.

WP Masquerade erkennt und blockiert keine SQL-Injection: Es ist keine Web Application Firewall. Wenn WordPress verborgen ist, lassen sich die installierten Plugins schwerer identifizieren, was manche Bots ausbremst, ein Update des verwundbaren Plugins ersetzt das aber nie.

Häufige Fehler

• „Von Hand“ escapen, mit addslashes() oder Zeichenersetzungen, statt eine vorbereitete Abfrage zu verwenden.
• Die Werte vorbereiten, aber einen Spaltennamen oder eine Sortierreihenfolge unverändert aus der Anfrage übernehmen: Nutze %i oder eine Positivliste.
• Glauben, dass sicher in der Datenbank gespeicherte Daten überall sicher sind: Bei der Ausgabe musst du Cross-Site-Scripting verhindern, durch Escaping.