Warum ändert WordPress wpdb->prepare % in eine zufällige Guid

Lesezeit: 3 Minuten

Das begann damit, dass ich versuchte, herauszufinden, wie ich etwas zum Laufen bringen könnte, und von der Ausgabe, die ich bekam, verblüfft war. Als ich überprüfte, ob ich diese Frage klar geschrieben hatte, stieß ich auf die Antwort. Jetzt stellt sich die Frage, WARUM es sich so verhält, da es für mich äußerst verwirrend war und mich glauben ließ, das Problem sei völlig anders als das, was es war.

Ich musste eine benutzerdefinierte Tabelle in der von mir erstellten WordPress-Datenbank abfragen. Ich brauchte mehrere Spalten und es könnte mehrere Zeilen geben, also habe ich verwendet $wpdb->get_results. Ich weiß jedoch, dass es sehr wichtig ist, SQL-Injection zu verhindern, daher wird dringend empfohlen, es in Verbindung mit zu verwenden $wpdb->prepare. In allen Beispielen, die ich gesehen habe, gibt es mehrere Möglichkeiten, die für andere zu funktionieren scheinen, wie zum Beispiel:

$wpdb->get_results($wpdb->prepare(
    "SELECT * FROM %s WHERE ADDRESS LIKE %%%s%%", $tableName, $address
));

oder

$wpdb->get_results($wpdb->prepare(
    "SELECT * FROM %s WHERE ADDRESS LIKE %s", $tableName, '%' . $address . '%'
));

Während ich dies entwickle, verwende ich jedoch eine Variable und drucke den Bildschirm für Debugging-Zwecke, wie:

$theQuery = $wpdb->prepare(
    "SELECT * FROM %s WHERE ADDRESS LIKE %s", $tableName, '%' . $address . '%'
);
printf(nl2br("theQuery: " . $theQuery . PHP_EOL));

Wenn ich mir die Ergebnisse ansehe, erhalte ich Folgendes:

theQuery: SELECT * FROM 'wp_table' WHERE ADDRESS LIKE '{38f7caa660e456637b3924006588169e1912b28c0a81d0a4ae0d77885704a425}11th ST{38f7caa660e456637b3924006588169e1912b28c0a81d0a4ae0d77885704a425}'

Es scheint wie die $wpdb->prepare -Anweisung bewirkt, dass % in GUIDs irgendeines Typs umgewandelt wird. Jedes Mal, wenn ich die Seite aktualisiere, ändert sich der Wert der GUIDs, sodass jedes Mal neue GUIDs für das %-Symbol generiert werden. Dies ist offensichtlich ein Teil der Art und Weise, wie es Sicherheit gegen SQL-Injektionen bietet, aber da ich nicht wusste, dass es sich so verhalten würde, und das nie in der Dokumentation gesehen habe, dachte ich, das wäre mein Problem. Ich habe so viele Kombinationen ausprobiert und es konnten immer keine Ergebnisse abgerufen werden, und ich dachte immer, es liege daran, dass es sich mit diesen GUIDs falsch verhält. Am Ende stellte ich fest, dass das TATSÄCHLICHE Problem darin bestand, den Tabellennamen als Parameter in die Anweisung zum Vorbereiten aufzunehmen. Es bewirkt, dass die Abfrage einfache Anführungszeichen um den Tabellennamen herum enthält, was zu einem MySQL-Syntaxfehler führt und keine Ergebnisse zurückgegeben werden.

Warum genau generiert es diese GUIDs und gibt es während des Testens eine Möglichkeit, sie zum Debuggen als % an den Browser zu drucken?

Danke schön!

Dies war eine Änderung, die in WordPress 4.8.3 vorgenommen wurde, um eine MySQL-Injection-Schwachstelle zu beheben. Hier sind einige Links mit weiteren Informationen.

https://make.wordpress.org/security/2017/11/13/the-war-on-sqli-or-what-happened-in-4-8-2-and-4-8-3/

https://blog.ircmaxell.com/2017/10/disclosure-wordpress-wpdb-sql-injection-technical.html

1446390cookie-checkWarum ändert WordPress wpdb->prepare % in eine zufällige Guid

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy