Seguridad

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

Visión general

This document is an analysis and explanation of the WordPress core software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating WordPress as a content management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.

The information in this document is up-to-date for the latest stable release of the software, WordPress 4.7 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the WordPress development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of WordPress to ensure the most secure experience possible.

Resumen ejecutivo

WordPress is a dynamic open-source content management system which is used to power millions of websites, web applications, and blogs. It currently powers more than 34% of the top 10 million websites on the Internet. WordPress’ usability, extensibility, and mature development community make it a popular and secure choice for websites of all sizes.

Since its inception in 2003, WordPress has undergone continual hardening so its core software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.

The WordPress Security Team, in collaboration with the WordPress Core Leadership Team and backed by the WordPress global community, works to identify and resolve security issues in the core software available for distribution and installation at WordPress.org, as well as recommending and documenting security best practices for third-party plugin and theme authors.

Site developers and administrators should pay particular attention to the correct use of core APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access WordPress.

Una visión general de WordPress

WordPress is a free and open source content management system (CMS). It is the most widely-used CMS software in the world and it powers more than 34% of the top 10 million websites1, giving it an estimated 60% market share of all sites using a CMS.

WordPress is licensed under the General Public License (GPLv2 or later) which provides four core freedoms, and can be considered as the WordPress “bill of rights”:

  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

The WordPress project is a meritocracy, run by a core leadership team, and led by its co-creator and lead developer, Matt Mullenweg. The team governs all aspects of the project, including core development, WordPress.org, and community initiatives.

The Core Leadership Team consists of Matt Mullenweg, five lead developers, and more than a dozen core developers with permanent commit access. These developers have final authority on technical decisions, and lead architecture discussions and implementation efforts.

WordPress has a number of contributing developers. Some of these are former or current committers, and some are likely future committers. These contributing developers are trusted and veteran contributors to WordPress who have earned a great deal of respect among their peers. As needed, WordPress also has guest committers, individuals who are granted commit access, sometimes for a specific component, on a temporary or trial basis.

The core and contributing developers primarily guide WordPress development. Every version, hundreds of developers contribute code to WordPress. These core contributors are volunteers who contribute to the core codebase in some way.

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ón<sup id="ref9"><a href="#footnote9">9</a></sup> 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 aegurar que lo datos facilitados por el usuario están a salvo<sup id="ref10"><a href="#footnote10">10</a></sup>. 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 <code>wp_kses</code>.

Como ejemplo, el equipo del núcleo de WordPress avisó antes del lanzamiento de WordPress 2.3 que la función <code>the_search_query()</code> 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 portaa. El tema por defecto incluido en el núcleo de WordPress (actualmente "Twenty Seventeen") ha sido 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 par 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 d 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 administrad 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.71, 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.

Recursos adicionales

Autorizado por Sara Rosso

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

Version 1.0 marzo 2015

Notas al pie