Wenn ein Hacker den blog_charset in UTF-7 ändert, macht dies WordPress anfällig für weitere Angriffe?

Ich hatte einen Kunden, der kürzlich gehackt wurde, und ich bemerkte, dass auf ihrer Website seltsame Charaktere wie  und Æ auftauchten. Es hat sich herausgestellt, dass die Hacker das blog_charset in der wp_optionsTabelle in der Datenbank in UTF-7 geändert haben . Ich habe es auf UTF-8 zurückgesetzt, aber ich habe mich gefragt, ob es während der Einstellung auf UTF-7 zu Sicherheitslücken kommen kann.

Ich habe ein bisschen gesucht und festgestellt, dass es früher eine WordPress UTF-7-Sicherheitslücke gab, die in Version 2.0.6 behoben wurde . Wir verwenden die neueste Version von WordPress, daher konnten sie diesen Exploit nicht verwenden. Gibt es jedoch andere Exploits im Zusammenhang mit UTF-7? Gibt es wirklich einen Grund, warum die Hacker den blog_charset ändern würden, außer dass dies ein Schmerz ist? Ich habe versucht herauszufinden, wie sie reingekommen sind und ich frage mich, ob das irgendwie zusammenhängt.

<und >sind als +ADw-und +AD4-in UTF-7 codiert . Stellen Sie sich nun Folgendes vor:

1. Jemand sendet +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-als Kommentar Text. Es wird alle sanitären Einrichtungen ungehindert passieren.

2. Die Datenbank erwartet und behandelt alle eingehenden Daten als UTF-8. Da alle UTF-7 - Streams gültige UTF-8 zu, wird dies nie in einem SQL - Fehler zur Folge haben , und mysql_real_escapeoder htmlspecialcharswird es nicht berühren.

3. WordPress sendet einen Header text/html;charset=utf-7.

4. WordPress zeigt den Kommentar an und erwartet entkommene Daten. Da dies jedoch vom Browser als UTF-7 behandelt wird, wird JavaScript ausgeführt.

Also ja, es ist ein Sicherheitsproblem.

UTF-7 wird nicht von allen Browsern unterstützt. Die meisten geben den Text als Windows-1252 (oder wie auch immer die Standardkodierung auf ihrem Betriebssystem lautet) oder als UTF-8 wieder. Das Hauptproblem ist: Flucht wird nicht mehr funktionieren.

Nur den Codierungswert zurück zu ändern, ist keine Lösung. Ein regelmäßiger Besucher kann es nie ändern, deshalb muss man die offene Tür finden.

Möglicherweise ist es auch erforderlich (alle Codierungen Ihrer Tabellen werden neu konvertiert): /programming/6115612/how-to-convert-anentire-mysql-database-characterset-and-collation- bis-utf-8