Seguridad

Aprende más sobre la seguridad del software base de WordPress en este manual gratuito. También puedes descargarlo en formato PDF.

Visión general

Este documento es un análisis y explicación del desarrollo del software base de WordPress y sus procesos de seguridad relacionados, así como una revisión de la seguridad inherente construida directamente en el software. Los responsables de decisiones que evalúen WordPress como sistema de gestión de contenidos o entorno de trabajo para aplicaciones web deberían usar este documento en su análisis y toma de decisiones, y los desarrolladores deberían remitirse a él para familiarizarse con los componentes y buenas prácticas de seguridad del software.

La información de este documento está actualizada para la última versión estable del software, WordPress 4.9 a la fecha de la publicación, pero debería considerarse relevante también en las versiones más recientes del software ya que la compatibilidad con versiones anteriores es un punto fundamental para el equipo de desarrollo de WordPress. Las medidas de seguridad específicas y los cambios se anotarán a medida que se añadan al software base en versiones específicas. Se recomienda encarecidamente ejecutar siempre la última versión estable de WordPress para asegurar la experiencia más segura posible.

Resumen ejecutivo

WordPress es un sistema de gestión de contenidos dinámico de código abierto utilizado para hacer funcionar millones de webs, aplicaciones web y blogs. Actualmente hace funcionar 35% de los principales 10 millones de webs de Internet. La usabilidad, extensibilidad y madura comunidad de desarrollo de WordPress hace que sea una elección segura para webs de todos los tamaños.

Desde su inicio n 2003, WordPress se ha fortalecido continuamente para que su su software base pueda detectar y mitigar amenazas comunes de seguridad, incluida la lista Top 10 identificada por el proyecto de seguridad de aplicaciones de la web abierta (OWASP) y las vulnerabilidades de seguridad más comunes, como se explica en este documento.

El equipo de seguridad de WordPress, en colaboración con el equipo líder de desarrollo de WordPress, y apoyados por la comunidad global WordPress, trabaja para identificar y resolver problemas de seguridad en el software base disponible en WordPress.org para su distribución e instalación, así como en recomendar y documentar las mejores prácticas de seguridad para autores de plugins y temas.

Los desarrolladores y administradores de sitios deberían prestar especial atención al uso correcto de las APIs y la configuración del servidor subyacente que hayan sido origen de vulnerabilidades comunes, así como asegurarse de que todos los usuarios utilizan contraseñas fuertes para acceder a WordPress.

Una visión general de WordPress

WordPress es un sistema de gestión de contenidos (CMS) gratuito y de código abierto. Es el CMS más utilizado del mundo y hace funcionar más del 35% de los 10 millones de sitios más grandes1, lo que se traduce en una estimación de una cuota de mercado del 62% de todos los sitios que utilizan un CMS.

WordPress está liberado bajo la licencia General Public License (GPLv2 o posterior), que proporciona cuatro libertades fundamentales que pueden ser consideradas la «declaración de derechos» de WordPress:

  1. La libertad de ejecutar el programa, para cualquier propósito.
  2. La libertad de estudiar cómo funciona el programa, y cambiarlo para hacerlo adecuarlo a tus deseos.
  3. La libertad de redistribuir.
  4. La libertad de distribuir copias de tus versiones modificadas a otros.

El equipo de liderazgo del núcleo de WordPress

El proyecto WordPress es una meritocracia dirigida por un equipo de liderazgo principal y guiada por su co-creador y jefe de desarrollo, Matt Mullenweg. El equipo gobierna todos los aspectos del proyecto, incluyendo el desarrollo del núcleo, WordPress.org y las iniciativas de la comunidad.

El equipo líder del núcleo lo componen Matt Mullenweg, cinco desarrolladores líderes y más de una docena de desarrolladores del núcleo que tienen acceso de validación permanente. Estos desarrolladores tienen la autoridad final sobre las decisiones técnicas, debates de arquitectura principal y esfuerzos de implementación.

WordPress tiene muchos desarrolladores colaboradores. Algunos de ellos son antiguos o actuales validadores, y algunos es posible que sean futuros validadores. Estos desarrolladores colaboradores son colaboradores fiables y veteranos de WordPress, que se han ganado un gran respeto entre sus colegas. Cuando se necesita, WordPress también tiene validadores invitados, individuos a los que se les concede acceso, a veces para un componente específico, para tareas temporales o de pruebas.

Los desarrolladores del núcleo y los colaboradores guían principalmente el desarrollo de WordPress. Cada versión cientos de desarrolladores contribuyen al código de WordPress. Estos colaboradores del núcleo son voluntarios que contribuyen al código base del núcleo en algún modo.

El ciclo de publicación de WordPress

Cada ciclo de versión de WordPress lo dirige uno o más de los desarrolladores del núcleo de WordPress. Un ciclo de versiones normalmente termina alrededor de 4 meses desde la reunión inicial hasta el lanzamiento de la versión.

Un ciclo de versión sigue el siguiente patrón2:

  • Fase 1: Líderes de planificación y del equipo de seguridad: Esto se realiza en la sala de chat #core de Slack. El líder de la versión debate sobre las características de la nueva versión de WordPress. Los colaboradores de WordPress se involucran en el debate. El líder de la versión identificará a lo líderes del equipo para cada una de las características.
  • Fase 2: Empieza el trabajo de desarrollo. Los líderes del equipo organizan los equipos y trabajan en las características que se les hayan asignado. Se programan charlas habituales para asegurar que el desarrollo sigue en marcha.
  • Fase 3: Beta. Se lanzan las betas, y a los probadores de beta se les pide que empiecen a informar de fallos. A partir de esta fase no se realizan más propuestas de nuevas mejoras o peticiones de características. A los autores de plugins y temas se les anima a probar su código frente los futuros cambios.
  • Fase 4: Lista para su lanzamiento. Hay un parón técnico para traducir los textos en este punto. El trabajo se centra solo en repasos y bloqueos.
  • Fase 5: Lanzamiento. Se lanza la versión de WordPress y está disponible para actualizar en la administración de WordPress.

Numeración de versiones y actualizaciones de seguridad

Una versión mayor de WordPress la dictan la primeras dos secuencias. Por ejemplo, 3.5 es una versión mayor, y 3.6, 3.7 o 4.0. No hay un «WordPress 3» o «WordPress 4» y cada versión mayor se refiere a su numeración, p.ej. «WordPress 3.9».

Las versiones mayores pueden añadir nuevas características de cara al usuario y APIs para desarrolladores. Aunque lo normal en el mundo del software una versión «mayor» significa que puedes romper la compatibilidad con versiones anteriores, WordPress trata de nunca romper la compatibilidad con versiones anteriores. La compatibilidad con versiones anteriores es una de las filosofías más importantes del proyecto, con el objetivo de hacer cada actualización más fácil para los usuarios y mejor para los desarrolladores.

Una versión menor de WordPress la dicta la tercera secuencia. La versión 3.5.1 es una versión menor, y la 3.4.23. Una versión menor se reserva para arreglar vulnerabilidades de seguridad y para solucionar solo fallos críticos. Como las nuevas versiones de WordPress se publican de manera tan frecuente — el objetivo es que haya una versión mayor cada 4-5 meses, y las versiones menores estarán disponibles a medida que se necesiten — solo son necesarias las versiones mayores y menores.

Compatibilidad con versiones anteriores

El proyecto WordPress tiene un fuerte compromiso con la compatibilidad con versiones anteriores. Este compromiso significa que los temas, plugins y el código personalizado sigan funcionando cuando se actualice el núcleo de WordPress, animando a los propietarios de sitios a mantener actualizada su versión de WordPress a la última versión segura.

WordPress y la seguridad

El equipo de seguridad de WordPress

El equipo de seguridad de WordPress está formado por aproximadamente 50 expertos, incluidos los desarrolladores líderes e investigadores de seguridad — cerca de la mitad son empleados de Automattic (creadores de WordPress.com, la primera y mayor plataforma de alojamiento WordPress en la web), y otros trabajan en el campo de la seguridad web. El equipo consulta a investigadores de seguridad fiables y conocidos y a empresas de alojamiento3.

El equipo de seguridad de WordPress a veces colabora con otros equipos de seguridad para solucionar problemas con dependencias comunes, tomo por ejemplo resolviendo la vulnerabilidad en el analizador XML de PHP, utilizado por la API XML-RPC que se incluye en WordPress, en WordPress 3.9.24. La solución a esta vulnerabilidad fue el resultado de un esfuerzo conjunto de los equipos de seguridad de WordPress y Drupal.

Riesgos, proceso e historia de la seguridad WordPress

El equipo de seguridad de WordPress cree en la divulgación responsable que alerte al equipo de seguridad inmediatamente de cualquier vulnerabilidad potencial. Se puede avisar al equipo de seguridad de vulnerabilidades potenciales de seguridad desde WordPress HackerOne5. El equipo de seguridad se comunica mediante un canal privado de Slack, y trabaja haciendo pruebas, seguimiento mediante Trac privado, y solucionando fallos y problemas de seguridad.

Cada informe de seguridad se responde al recibirlo, y el equipo trabaja para verificar la vulnerabilidad y determinar su severidad. Si se confirma, el equipo de seguridad entonces planifica un parche para solucionar el problema, que puede lanzarse en una próxima versión del software WordPress o puede lanzarse como una versión inmediata de seguridad, dependiendo de la severidad del problema.

Cuando hay una actualización de seguridad inmediata el equipo de seguridad publica un aviso en las noticias6 del sitio WordPress.org anunciando la versión y detallando los cambios. Se agradece la divulgación responsable cuando se avisa de una vulnerabilidad para apoyar y reforzar el informe responsable continuo en el futuro.

Los administradores del software WordPress ven un aviso en el escritorio de su sitio para que actualicen cuando hay una nueva versión disponible, y tras las actualizaciones manuales a los usuarios se les redirige a una pantalla de Acerca de WordPress con detalles de los cambios. Si los administradores tienen activas las actualizaciones en segundo plano recibirán un correo electrónico después de que se complete una actualización.

Actualizaciones automáticas en segundo plano para versiones de seguridad

En la versión 3.7 WordPress introdujo las actualizaciones automáticas en segundo plano para todas las versiones menores7, como la 3.7.1 y la 3.7.2. El equipo de seguridad de WordPress puede identificar, arreglar y lanzar mejoras de seguridad automáticas para WordPress sin que el propietario del sitio tenga que hacer nada por su parte, y la actualización de seguridad se instalará automáticamente.

Cuando se lanza una actualización de seguridad para la versión estable actual de WordPress, el equipo del núcleo también lanza actualizaciones de seguridad para todas las versiones capaces de ejecutar actualizaciones en segundo plano (desde WordPress 3.7) para que estas versiones anteriores, pero aún recientes, de WordPress también reciban mejoras de seguridad.

Los propietarios de sitios individuales pueden optar por quitar las actualizaciones automáticas en segundo plano mediante un sencillo cambio en su archivo de configuración, pero el equipo del núcleo recomienda encarecidamente mantener activa la funcionalidad, así como ejecutar la última versión estable de WordPress.

Top 10 2013 de OWASP

El Open Web Application Security Project / Proyecto de seguridad para aplicaciones web abiertas (OWASP) es una comunidad online dedicada a la seguridad en aplicaciones web. La lista Top 108 de la OWASP se enfoca en identificar los riesgos de seguridad más serios en aplicaciones en un amplio espectro de organizaciones. Los elementos del Top 10 se eligen priorizan en combinación con estimaciones consensuadas de explotabilidad, detectabilidad e impacto estimado.

Las siguientes secciones tratan sobre APIs, recursos y políticas que usa WordPress para fortalecer el software base y plugins y temas de terceros frente a estos riesgos potenciales.

A1 - Inyección

Hay un conjunto de funciones y APIs disponibles en WordPress para ayudar a los desarrolladores a asegurar que no se pueda inyectar código, y para ayudarles a validar y sanear datos. Hay disponibles buenas prácticas y documentación9 sobre cómo usar estas APIs para proteger, validar o sanear introducción y salida de datos en HTML, URLs, cabeceras HTTP y cuando se interactúa con la base de datos y el sistema de archivos. Los administradores pueden también incluso restringir mediante filtros los tipos de archivos que pueden subirse.

A2 - Gestión de identificación rota y de sesión

El software base de WordPress gestiona las cuentas de usuario, la identificación y detalles tales como el ID de usuario y el nombre, y las contraseñas se gestionan desde el servidor así como las cookies de identificación. Las contraseñas se protegen en la base de datos usando técnicas estándar de salt y dilatación. Las sesiones activas se cierran al desconectar en las versiones de WordPress a partir de la 4.0.

A3 - Cross Site Scripting (XSS)

WordPress ofrece un amplio rango de funciones que pueden ayudar a asegurar que los datos facilitados por el usuario están a salvo10. Los usuarios fiables, como los administradores y editores de una instalación simple de WordPress, y solo los administradores de la red en un WordPress multisitio, pueden publicar HTML sin filtrado o JavaScript si lo necesitan, como por ejemplo dentro de una entrada o página. Lo usuarios no fiables y el contenido enviado por los usuarios se filtra por defecto para eliminar las entidades peligrosas, usando la biblioteca KSES mediante la función wp_kses.

Como ejemplo, el equipo del núcleo de WordPress avisó antes del lanzamiento de WordPress 2.3 que la función the_search_query() se estaba usando mal por parte de la mayoría de los autores de temas, que no estaban escapando la salida de la función para su uso en HTML. En un muy extraño caso de ligera ruptura con la compatibilidad con versiones anteriores, la salida de la función se cambió en WordPress 2.3 para que se escapase previamente.

A4 - Referencia directa a objetos inseguros

WordPress a menudo ofrece referencia directa a objetos, como identificadores numéricos únicos de las cuentas de usuario, del contenido disponible en la URL o de los campos de un formulario. Aunque estos identificadores revelan información directa del sistema, el amplio sistema de control de acceso y permisos de WordPress impide solicitudes no autorizadas.

A5 - Mala configuración de seguridad

La mayoría de las operaciones de configuración de seguridad de WordPress están limitadas a un único administrador autorizado. Los ajustes por defecto de WordPress se evalúan continuamente a nivel del núcleo, y el equipo del núcleo de WordPress ofrece documentación y buenas prácticas para fortalecer la seguridad en la configuración del servidor a la hora de ejecutar un sitio WordPress11.

A6 - Revelación de datos sensibles

Las contraseñas de usuario de WordPress están basadas en salts y hashs en el marco de trabajo de hash de contraseñas portátil de PHP12. El sistema de permisos de WordPress se utiliza para controlar el acceso a información privada como la PII (información privada personal) de los usuarios registrados, correos electrónicos de los comentaristas, contenido publicado en privado, etc. En WordPress 3.7 se incluyó en el software base un medidor de fortaleza de contraseñas para ofrecer información adicional a los usuarios a la hora de configurar sus contraseñas, y trucos para aumentar su fortaleza. WordPress también tiene un ajuste opcional de configuración para requerir HTTPS.

A7 - Nivel de control de acceso a funciones no encontradas

WordPress comprueba la correcta autorización y permisos de cualquier nivel de petición acceso de una función antes de ejecutar la acción. El acceso o visualización de URLs de administración, menús y páginas sin la identificación adecuada está fuertemente integrada con el sistema de identificación para impedir acceso a usuarios sin autorización.

A8 - Cross Site Request Forgery / Peticiones falsas en sitios cruzados (CSRF)

WordPress utiliza tokens criptográficos, llamados nonces13, para validar intentos de peticiones de acciones desde usuarios autorizados para protegerse contra potenciales amenazas CSRF. WordPress ofrece una API para la generación de estos tokens con la que crear y verificar tokens únicos y temporales, y el token está limitado a un usuario específico, una acción específica, un objeto específico y un periodo de tiempo específico, que puede añadirse a formularios y URLs según se necesite. Adicionalmente, todas las nonces quedan sin validar al desconectar.

A9 - Uso de componentes con vulnerabilidades conocidas

El equipo del núcleo de WordPress vigila de cerca las pocas bibliotecas incluidas y los entornos de trabajo que integra WordPress en la funcionalidad de su núcleo. En al pasado, el equipo del núcleo hizo colaboraciones a diversos componentes de terceros para hacerlos más seguros, como por ejemplo para solucionar una vulnerabilidad cross-site en TinyMCE en WordPress 3.5.214.

Si fuese necesario, el equipo del núcleo puede decidir bifurcar o reemplazar componentes externos críticos, tales como cuando la biblioteca SWFUpload se reemplazó oficialmente por la biblioteca Plupload en la versión 3.5.2, y el equipo de seguridad hizo disponible una bifurcación segura de SWFUpload<15 para aquellos plugins que seguían usando SWFUpload de momento.

A10 - Redirecciones y envíos sin validar

El sistema de identificación y control de acceso interno de WordPress protegerá de intentos de dirigir a los usuarios a destinos no deseados y de redirecciones automáticas. Esta funcionalidad también está disponible para desarrolladores de plugins mediante una API, wp_safe_redirect()16.

Más riesgos y problemas de seguridad

Ataques de procesamiento XXE (XML eXternal Entity / Entidad externa XML)

Al procesar el XML, WordPress desactiva la carga de entidades XML personalizadas para impedir ataques tanto de entidades externas como en entidades expandidas. Más allá de la funcionalidad del núcleo de PHP, WordPress no ofrece una API de procesamiento seguro XML adicional a los autores de plugins.

Ataques SSRF (Server Side Request Forgery / Peticiones falsas al servidor)

Las peticiones HTTP enviadas por WordPress se filtran para evitar accesos a bucle de retorno y direcciones IP privadas. Adicionalmente, el acceso solo se permite a ciertos puertos HTTP estándar.

Seguridad de temas y plugins WordPress

El tema por defecto

WordPress requiere un tema activo para mostrar el contenido visible en la portada. El tema por defecto incluido en el núcleo de WordPress (actualmente «Twenty Twenty») se ha revisado intensamente, y comprobado por motivos de seguridad tanto por el equipo de desarrollo de temas como por el equipo de desarrollo del núcleo.

El tema por defecto puede servir de punto de comienzo para el desarrollo de temas a medida, y los desarrolladores pueden crear un tema hijo que incluya algunas personalizaciones aunque dependan del tema por defecto la mayor parte de las funcionalidades y seguridad. El tema por defecto puede borrarlo un administrador fácilmente si no lo necesita.

Directorios de temas y plugins de WordPress.org

Hay aproximadamente +50.000 plugins y +5.000 temas en el sitio WordPress.org. Estos temas y plugins se envían para su inclusión y los revisan manualmente voluntarios antes de hacer que estén disponibles en el directorio.

La inclusión de plugins y temas en el directorio no es una garantía de que estén libres de vulnerabilidades de seguridad. Se ofrecen directrices a los autores de plugins para que las consulten antes de enviar cualquier inclusión en el directorio17, y en el sitio WordPress.org se ofrece extensa documentación sobre como hacer desarrollo de temas18.

Cada plugin y tema tiene la posibilidad de ser desarrollado continuamente por el propietario del plugin o tema, y cualquier arreglo o característica posterior o futuro desarrollo puede subirse al directorio y hacer que esté disponible para los usuarios con ese plugin o tema instalado con una descripción de lo que ha cambiado. A los administradores de los sitios se les avisa de los plugins que tienen que actualizarse desde el escritorio de administración.

Cuando el equipo de seguridad de WordPress descubre una vulnerabilidad contactan con el autor del plugin y trabajan juntos para solucionar y lanzar una versión segura del plugin. Si hay alguna falta o retraso en la respuesta por parte del autor del plugin o si la vulnerabilidad es grave, el plugin/tema se retira del directorio público y, en algunos casos, lo arregla y actualiza directamente el equipo de seguridad.

El equipo de revisión de temas

El equipo de revisión de temas es un grupo de voluntarios, liderados por miembros clave estables de la comunidad WordPress, que revisan y aprueban los temas enviados para incluirse en el directorio oficial de temas WordPress. El equipo de revisión de temas mantiene las directrices de revisión de temas19, los datos de prueba20 y los plugins de comprobación de temas21, y trata de involucrar y educar a la comunidad de desarrollo de temas WordPress en las mejores prácticas de desarrollo. La inclusión en este grupo la moderan los validadores principales del equipo de desarrollo de WordPress.

El papel del proveedor de alojamiento en la seguridad WordPress

WordPress puede instalarse en multitud de plataformas. Aunque el núcleo de WordPress ofrece muchas garantías para operar una aplicación web segura, que hemos cubierto en este documento, la configuración del sistema operativo y el software instalado en el servidor web del alojamiento son igualmente importantes para mantener aplicaciones WordPress seguras.

Una nota sobre WordPress.com y la seguridad en WordPress

WordPress.com es la mayor instalación de WordPress del mundo, y es propiedad y la administra Automattic Inc, fundada por Matt Mullenweg, el co-creador del proyecto WordPress, y tiene sus propios procesos, riesgos y soluciones de seguridad22. Este documento se refiere a la seguridad respecto al software WordPress de código abierto, alojado por tu cuenta, descargable y disponible en WordPress.org, que puedes instalar en cualquier servidor del mundo.

Apéndice

APIs del núcleo de WordPress

La interfaz de programación de aplicaciones (API) del núcleo de WordPress comprende varias APIs23 individuales, y cada una de ellas cubre las funciones que cubre y utiliza, para un conjunto dado de funcionalidades. Juntas, forman la interfaz del proyecto que permite a los plugins y temas interactuar, alterar y ampliar el núcleo de WordPress de forma sana y segura.

Aunque cada API de WordPress ofrece las mejores prácticas y métodos estandarizados para interactuar y ampliar el software del núcleo de WordPress, las siguientes APIs de WordPress son las más pertinentes para reforzar la seguridad de WordPress:

API de la base de datos

La API de la base de datos24, añadida en WordPress 0.7.1, ofrece el método correcto de acceder a los datos como valores con nombre que se almacenan en la capa de la base de datos.

API del sistema de archivos

La API del sistema de archivos25, añadida en WordPress 2.626, se creó originalmente para la característica de actualizaciones automáticas propia de WordPress. La API del sistema de archivos abstrae la funcionalidad necesaria para leer y escribir archivos locales en el sistema de archivos para hacerlo con seguridad, y una gran variedad de tipos de alojamiento.

Lo hace mediante la clase WP_Filesystem_Base y diversas subclases que implementan distintas maneras de conectar con el sistema de archivos local, dependiendo de la compatibilidad de cada alojamiento. Cualquier tema o plugin que necesite escribir archivos localmente debería usar la familia de clases WP_Filesystem.

API HTTP

La API HTTP27, añadida en WordPress 2.728 y ampliada en WordPress 2.8, estandariza las peticiones HTTP de WordPress. La API gestiona las cookies, la codificación y decodificación gzip, la decodificación en partes (si es HTTP 1.1) y otras diversas implementaciones del protocolo HTTP. La API estandariza las peticiones, comprueba cada método antes de enviarlo, y, basándose en la configuración de tu servidor, utiliza el método más adecuado para hacer la petición.

Permisos y la API del usuario actual

Los permisos y la 29la API del usuario actual es un conjunto de funciones que ayudarán a verificar los permisos y autoridad del usuario actual para llevar a cabo cualquier tarea u operación solicitada, y puede proteger contra accesos de usuarios no autorizados o de realizar funciones más allá de sus capacidades permitidas.

Licencia del manual de contenido

El texto de este documento (sin incluir el logotipo de WordPress o la marca registrada) está bajo la licencia CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Puedes copiarlo, modificarlo, distribuirlo y realizar trabajos con él, incluso con propósitos comerciales, todo sin tener que pedir permiso.

Un agradecimiento especial al manual de seguridad de Drupal, que ofreció algo de inspiración.

Para seguir leyendo

Creado por Sara Rosso

Colaboraciones de Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Version 1.0 marzo 2015

Notas al pie