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:
- Coger datos pasados a una función.
- ¿¿¿???.
- Hacer la llamada SQL.
Y cambiarlo a:
- Coger datos pasados a una función.
- Escaparlos (filtrarlos).
- 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):
-
Desactivar los mensajes de error SQL debido a que ofrecen demasiada información a potenciales atacantes.
-
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.
Comentarios