Si un hacker cambió el blog_charset a UTF-7, ¿eso hace que WordPress sea vulnerable a nuevos ataques?

Tuve un cliente que fue pirateado recientemente y noté que aparecían personajes extraños en su sitio, como  y Æ. Resulta que los hackers cambiaron el blog_charset a UTF-7 en la wp_optionstabla de la base de datos. Lo configuré de nuevo en UTF-8, pero me preguntaba si durante el tiempo que se configuró en UTF-7, ¿podría eso crear alguna vulnerabilidad de seguridad?

Hice algunas búsquedas y descubrí que solía haber una vulnerabilidad UTF-7 de WordPress que se corrigió en la versión 2.0.6 . Estamos ejecutando la versión más reciente de WordPress, por lo que no podrían haber utilizado ese exploit, pero ¿hay otros exploits relacionados con UTF-7? Realmente, ¿hay alguna razón para que los hackers cambien el blog_charset aparte de ser una molestia? He estado tratando de determinar cómo entraron y me pregunto si esto está conectado de alguna manera.

<y >están codificados como +ADw-y +AD4-en UTF-7 . Ahora imagine lo siguiente:

1. Alguien envía +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-como texto de comentario. Pasará todo el saneamiento sin escapes.

2. La base de datos espera y trata todos los datos entrantes como UTF-8. Puesto que todas las UTF-7 corrientes son UTF-8 válido también, esto nunca va a dar lugar a un error de SQL y, mysql_real_escapeo htmlspecialcharsno lo tocará.

3. WordPress envía un encabezado text/html;charset=utf-7.

4. WordPress muestra el comentario, esperando datos escapados. Pero como el navegador lo trata como UTF-7, se ejecutará JavaScript.

Entonces, sí, es un problema de seguridad.

UTF-7 no es compatible con todos los navegadores, la mayoría representará el texto como Windows-1252 (o la codificación predeterminada en su sistema operativo) o como UTF-8. El principal problema es: escapar ya no funcionará.

Simplemente cambiar el valor de codificación de nuevo no es una solución. Un visitante habitual nunca puede cambiarlo, por lo que debe encontrar la puerta abierta.

Además, podría ser necesario (volver a convertir todas las codificaciones de sus tablas): /programming/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation- to-utf-8