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

Navega tus respuestas
19

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

Hice una búsqueda y descubrí que solía haber una vulnerabilidad de WordPress UTF-7 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 por la que los hackers cambiarían el blog_charset para que no fuera un problema? He estado tratando de determinar cómo entraron y me pregunto si esto está conectado de alguna manera.

    
pregunta Jennette 24.12.2012 - 03:28

2 respuestas

23

< y > están codificados como +ADw- y +AD4- en UTF-7 . Ahora imagina 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 escaparse.

  2. La base de datos espera y trata todos los datos entrantes como UTF-8. Ya que todas las transmisiones de UTF-7 también son válidas de UTF-8, esto nunca dará como resultado un error de SQL, y mysql_real_escape o htmlspecialchars no lo tocarán.

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

  4. WordPress muestra el comentario, esperando datos de escape. Pero como esto se trata como UTF-7 en el navegador, 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 cualquiera que sea la codificación predeterminada en su sistema operativo) o como UTF-8. El problema principal es: escapar ya no funcionará.

El simple hecho de volver a cambiar el valor de codificación no es una solución. Un visitante habitual nunca puede cambiarlo, por lo que tienes para encontrar la puerta abierta.

    
respondido por el fuxia 24.12.2012 - 03:59
0

También, podría ser necesario (volver a convertir todas las codificaciones de sus tablas): enlace

    
respondido por el tfont 10.02.2017 - 16:28

Lea otras preguntas en las etiquetas

Usando la API de reescritura para construir una URL RESTful ¿Complementos en directorios con enlaces simbólicos?