Seguridad en WordPress: ¿podríamos vivir sin plugins?

Vía el Planet Webdev acabo de leer a Alex que comenta dos noticias relacionadas a la seguridad en WordPress. Un tema candente. Copio (corrigiendo un “propuesta” de más) los dos puntos de la entrada de Alex:

• Existe una propuesta para cambiar la forma en que se interactúa con la base de datos, esto es, utilizar una especie de consultas parametrizadas basadas en sprintf para evitar el gran número de problemas de SQL Injection que existe con el esquema actual (que en realidad hace lo mismo que [magic_quotes](http://php.net/magic_quotes).
• Entrevista a Steffan Esser sobre el estado de la seguridad de WordPress.

El primer enlace es un punto importante y es cambiar la forma de realizar consultas SQL que actualmente es:

1. Coger datos pasados a una función.
2. ¿¿¿???.
3. Hacer la llamada SQL.

Y cambiarlo a:

1. Coger datos pasados a una función.
2. Escaparlos (filtrarlos).
3. Hacer la llamada SQL.

Con esto los fallos de inyección SQL serian más fáciles de descubrir y al mismo tiempo hará que sean más difíciles de explotar.

Por otro lado, en la entrevista Steffan dice algunos puntos muy interesantes:

• Cree que WordPress es el mejor software/CMS para “blogging” actualmente pero que han cometido malas decisiones de diseño.

  Por ejemplo considera que bastantes funcionalidades son “peligrosas” como por ejemplo el sistema de editar plantillas que obliga a dar permisos de escritura. Si un usuario consigue permisos para editar plantillas (por ejemplo en un descuido del administrador) puede editar las plantillas para ejecutar cualquier código PHP en el servidor.

• Crítica la forma de anunciar los fallos de seguridad. Cuando corriges un fallo de seguridad explotable remotamente que permite ejecutar código y hay información pública de cómo hacerlo no puedes esperar a sacar una versión corregida.

  Además es totalmente inaceptable que se escuden en “es un fallo sólo explotable con register_globals en ON cuando la mayoría de hostings todavía lo tienen activo (¡¡!!) sin ir más lejos el propio wordpress.org (¡¡!! x2).

• Cree que WordPress deberia invertir dinero en auditar el software.

• ¿Alternativas? Serendipity/S9Y el cual opina que tiene un código de mayor calidad pero que no es “user-friendly”.

Por último da dos recomendaciones (en realidad dos cosas que cambiaría de WordPress pero puede ser perfectamente dos cambios que uno mismo puede realizar):

1. Desactivar los mensajes de error SQL debido a que ofrecen demasiada información a potenciales atacantes.

2. Asegurarse de no usar el prefijo de las tablas SQL por defecto (wp_) durante la instalación.

“Cuando estos dos cambios sean implementados (quizá ya lo han sido desde la última vez que probe WordPress), entonces las inyecciones SQL en WordPress serán mucho más difíciles de explotar”.

Ahora la pregunta que yo hago es ¿seriamos capaces de vivir sin plugins?, quien más quien menos tiene media docena como mínimo, yo al menos intento evitar el abuso de ellos pero dudo mucho que se pueda.

• Relacionada: Cinco consejos de seguridad en WordPress.

9 Comentarios

1. g30rg3_x:
   

   Yo creo que no se puede vivir sin plugins…

   La base fuerte de WordPress se base en la capacidad de expansion y crecimiento por parte de la comunidad, ya que la comunidad crea esas pequeñas partes que WordPress no piensa incluir en un buen largo tiempo y para claro no llenar de feauteres que ni al caso…

   El problema como dicen viene de que mucha gente que hace plugins no considera en ningun momento la seguridad del mismo, solo consideran que realize su accion no que sea seguro y efectivo, yo solo tengo en mente dos soluciones…
   La creacion de una framework para desarrollo de plugins, pero tiene una contra y es que se limita mucho la capacidad del programador ya que el ambiente controlado limitara las posibilidades de expansion.
   La segunda es simplemente implementar un sistema de actualizaciones estilo firefox para saber en que versiones andan cada plugin y si es necesario bajar la nueva version.

   En fin ideas hay, yo creo que la mayoria de la critica de steffan (sin desacreditar a este excelente auditor) es por que wordpress responde muy lento los problemas de seguridad en el sentido de que esperan el ciclo completo para brindar parches a la comunidad y no debe ser asi, debe ser que se saquen revisiones cuando menos para controlar estas versiones chiquitas de wordpress..

   Saludos

   Friday, 29 de June/2007 @ 6:03

2. alex:
   

   Si es que el spam, problemas de rendimiento, corrección de funcionalidad, etc. no tiene importancia alguna, creo que se podría vivir.

   Por otro lado, en [1], Mark Jaquith — desarrollador de WordPress — revela algunos aspectos internos sobre las falencias que existen en el tratamiento de los problemas de seguridad, que de algún modo explican porque no se liberan actualizaciones de seguridad.

   [1] http://markjaquith.wordpress.com/2007/06/28/wordpress-security/

   PS. Gracias por hacer notar el error ;)

   Friday, 29 de June/2007 @ 6:48

3. Gura:
   

   Pues yo no tengo una docena. Uno para tags, todo para administración bajo SSL, otro para la busqueda y na mas. Respecto a el prefijo de las tablas por defecto lo veo importantísimo, pues un atacante iría de cabeza a los wp_*. Sin embargo no se a que te refieres con “Desactivar los mensajes de error SQL debido a que ofrecen demasiada información a potenciales atacantes.”. Vamos, tal cual lo dices… no lo entiendo. He tocado en PHP el ocultar errores de código y registrarlos, pero de SQL no me suena. Lo buscaré ahora. Sería de agradecer que me orientases respecto a esto último. Luego el hardening del servidor, que como yo no tengo un tráfico desmesurable, lo tengo en casa, a mi bola.

   A mi también me preocupa la forma de publicar los fallos de seguridad. Esperar a la nueva revisión es impensable. Por suerte Alex publica en su web interesantes artículos que apuntan a los tiquets oficiales donde están disponibles los diff para modificar el código. SI la gestión de parches de seguridad fuese más efectiva estaría más tranquilo. Por otro lado los plugins, código que no es “auditado” por el equipo de wordpress, un código que es de terceros… La verdad es que no es todo de color de rosa.

   PD: Es que estos días estoy haciendo una migración a WordPress.

   Friday, 29 de June/2007 @ 12:36

4. Armonth:
   

   Si descontamos el wp-cache (del cual su autor al menos no comete fallos de seguridad muy a menudo), el akismet (código oficial) y el wp-db-backup (que no uso) me quedan:

   - UTW (a la espera de una migración a un 2.2.x o 2.3.x con tagging)
   - Plugins de formateo que no creo que sean muy perjudicales (un array y poco más).
   - Administración

   Gura: cuando una llamada SQL es incorrecta, el error que devuelve por defecto WordPress (PHP, MySQL, etcétera) incluye parte o toda la sentencia y eso ayuda a conocer más sobre la base de datos. Lo mismo para nombres de funciones que fallan y te orientan sobre qué plugins hay instalados…

   Friday, 29 de June/2007 @ 16:48

5. Gura:
   

   Ajá, ¿Pero como podría desactivarlo? Mejor dicho, es algo que hay que modificar a nivel de código en WordPress o es tema de la configuración de PHP?

   Friday, 29 de June/2007 @ 18:11

6. Armonth:
   

   Normalmente en PHP, directivas “display_errors” y “error_reporting” la primera para activar/desactivar (on/off) y la segunda para elegir en caso de activarse el grado de detalle (E_ALL, E_WARNING, etcétera).

   Creo recordar que había una manera de activarlo/desactivarlo añadiendo al principio del script un código PHP y así no tener que recurrir al php.ini pero ahora no lo recuerdo.

   Friday, 29 de June/2007 @ 20:47

7. Gura:
   

   Ajá. Lo tengo paliado entonces :) Lo de tirar del codigo en PHP para hacerlo lo mire un dia, pero solo para saber que función era y bloquearla en el php.ini. De momento todo correcto. Gracias.

   Friday, 29 de June/2007 @ 20:55

8. g30rg3_x:
   

   Bueno realmente apagar los errores de PHP no resuelve el problema de reporte de informacion o de errores (al menos no para todo) del que habla steffan esser.

   Lo que pasa es que WordPress tiene una clase para abstraer la BD (wp-db.php en wp-includes) y desde ahi se imprimen los errores directamente atravez de la funcion print_error() (lineas 119 a 137), claro todo depende si la variable show_errors esta puesta a verdadero (dos funciones se encargan de prender y apagar esta misma), pero desgraciadamente como dice steffan el reporte de errores esta activado por defecto…

   Para desactivalor basta con ir al archivo, linea 18 encontraremos:
   var $show_errors = true;
   Debemos cambiarlo por:
   var $show_errors = false;

   Con eso por defecto ahora si no se imprimira ningun resultado, de todos modos dentro de la misma clase existe la manera de prender (como dije anteriormente) de prender y apagar la misma, si son medio paranoicos y no quieren que bajo ninguna circunstancia se prenda el reporte de errores (ya que como dije un desarrollador de plugins o de temas lo puede prender), vayanse a la linea 143 del mismo archivo, van a encontrar:
   $this->show_errors = true;
   Solo cambien el enunciado a false…
   $this->show_errors = false;

   Con eso bajo cualquier circunstancia la base de datos no imprimira nada y si claro esto le suman que no imprima errores PHP, se tendra una mejor solucion.

   Saludos

   Friday, 29 de June/2007 @ 21:07

9. Gabriel:
   

   Yo también tengo unos cuantos. Normalmente activo solo aquellos que veo interesantes y mientras los veo útiles.
   Los uso por temporadas, salvo unos cuantos que son fijos. Son necesarios

   Saturday, 30 de June/2007 @ 8:48

Comentarios cerrados