Seguridad

Aprende más sobre la seguridad del software principal de WordPress en este documento técnico gratuito. También puedes descargarlo en formato PDF.

Resumen

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 dinámico de gestión de contenidos de código abierto que se utiliza para impulsar millones de webs, aplicaciones web y blogs. Actualmente gestiona más del 43% de los 10 millones de webs más visitadas de Internet. La usabilidad, la capacidad de ampliación y la madura comunidad de desarrollo de WordPress lo convierten en una opción popular y 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.

Visión general de WordPress

WordPress es un sistema de gestión de contenidos (CMS) gratuito y de código abierto. Es el software de gestión de contenidos más utilizado en el mundo y gestiona más del 43% de los 10 millones de webs más importantes¹, lo que supone una cuota de mercado estimada del 62% de todas las webs 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 «carta de derechos» de WordPress:

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

El equipo líder 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 versiones 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 lanzamiento sigue el siguiente patrón²:

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 versiones de seguridad

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

Las versiones mayores pueden añadir nuevas características para el usuario y APIs para desarrolladores. Aunque normalmente en el mundo del software, una versión «mayor» significa que se puede romper la retrocompatibilidad, WordPress se esfuerza por no romper nunca la retrocompatibilidad. La retrocompatibilidad es una de las filosofías más importantes del proyecto, con el objetivo de que las actualizaciones sean mucho más sencillas tanto para los usuarios como para los desarrolladores.

Una versión menor de WordPress viene dictada por el tercer número de la secuencia. La versión 3.5.1 es una versión menor, al igual que la 3.4.2³. Las versiones menores se reservan para solucionar vulnerabilidades de seguridad y errores críticos. Dado que las nuevas versiones de WordPress se publican con tanta frecuencia -el objetivo es que cada 4-5 meses se publique una versión mayor, y que las versiones menores se publiquen cuando sea necesario-, solo se necesitan 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 seguridad

El equipo de seguridad de WordPress

El equipo de seguridad de WordPress está formado por unos 50 expertos, entre desarrolladores principales e investigadores de seguridad. Aproximadamente la mitad son empleados de Automattic (creadores de WordPress.com, la primera y mayor plataforma de alojamiento de WordPress en Internet), y otros trabajan en el campo de la seguridad web. El equipo consulta a investigadores de seguridad y empresas de alojamiento conocidas y de confianza³.

El equipo de seguridad de WordPress colabora a menudo con otros equipos de seguridad para solucionar problemas en dependencias comunes, como la resolución de la vulnerabilidad en el analizador PHP XML, utilizado por la API XML-RPC que se incluye con WordPress, en WordPress 3.9.2⁴. La resolución de esta vulnerabilidad ha sido el resultado de un esfuerzo conjunto de los equipos de seguridad de WordPress y Drupal.

Riesgos, proceso e histórico de seguridad de WordPress

El equipo de seguridad de WordPress cree en la divulgación responsable, alertando al equipo de seguridad inmediatamente de cualquier vulnerabilidad potencial. Las posibles vulnerabilidades de seguridad se pueden transmitir al equipo de seguridad a través de WordPress HackerOne⁵. El equipo de seguridad se comunica entre sí a través de un canal privado de Slack, y trabaja en un Trac privado para rastrear, probar y solucionar errores 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.

Para un comunicado de seguridad inmediato, el equipo de seguridad publica un aviso en el sitio de noticias de WordPress.org⁶&nbspanunciando el lanzamiento y detallando los cambios. En el aviso se reconoce el mérito de la revelación responsable de una vulnerabilidad para fomentar y reforzar en el futuro el envío continuado de información responsable.

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

A partir de la versión 3.7, WordPress introdujo actualizaciones automáticas en segundo plano para todas las versiones menores⁷, como por ejemplo de la 3.7.1 a la 3.7.2. El equipo de seguridad de WordPress puede identificar, corregir y enviar mejoras de seguridad automatizadas para WordPress sin que el propietario del sitio tenga que hacer nada, 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 proyecto de seguridad de aplicaciones web abiertas (OWASP) es una comunidad en línea dedicada a la seguridad de las aplicaciones web. La lista OWASP Top 10⁸ se centra en la identificación de los riesgos de seguridad de aplicaciones más graves para una amplia gama de organizaciones. Los 10 principales elementos se seleccionan y priorizan en combinación con estimaciones consensuadas de explotabilidad, detectabilidad y estimaciones de impacto.

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

Existe un conjunto de funciones y API disponibles en WordPress para ayudar a los desarrolladores a asegurarse de que no se puede inyectar código no autorizado, y ayudarles a validar y sanear los datos. Hay documentación y buenas prácticas disponibles⁹&nbspsobre cómo usar estas APIs para proteger, validad o sanear los datos entrantes y salientes en el HTML, URLs, cabeceras HTTP, y al interactuar con la base de datos y el sistema de archivos. Los administradores también pueden restringir aún más los tipos de archivos que pueden cargarse mediante filtros.

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 una serie de funciones que pueden ayudar a garantizar la seguridad de los datos suministrados por los usuarios¹⁰. Los usuarios de confianza, es decir, los administradores y editores en una instalación individual de WordPress, y los administradores de red sólo en WordPress Multisite, pueden publicar HTML o JavaScript sin filtrar cuando lo necesiten, como por ejemplo dentro de una entrada o página. Los usuarios que no son de confianza y el contenido enviado por los usuarios se filtra por defecto para eliminar entidades peligrosas, utilizando la biblioteca KSES a través de la función wp_kses.

Como ejemplo, el equipo del núcleo de WordPress se dio cuenta antes del lanzamiento de WordPress 2.3 que la función the_search_query() estaba siendo mal utilizada por la mayoría de los autores de temas, que no escapaban la salida de la función para su uso en HTML. En un caso muy raro de romper ligeramente la retrocompatibilidad, la salida de la función fue cambiada en WordPress 2.3 para ser pre-escapada.

A4 – Referencia directa a objetos inseguros

WordPress proporciona a menudo referencias directas a objetos, como identificadores numéricos únicos de cuentas de usuario o contenidos disponibles en la URL o en campos de formularios. Si bien estos identificadores revelan información directa del sistema, los amplios permisos y el sistema de control de acceso de WordPress impiden las 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 para WordPress se evalúan continuamente a nivel del equipo del núcleo, y el equipo del núcleo de WordPress proporciona documentación y las mejores prácticas para reforzar la seguridad de la configuración del servidor para ejecutar un sitio WordPress¹¹.

A6 – Revelación de datos sensibles

Las contraseñas de las cuentas de usuario de WordPress se cifran con salt y hash según el framework portátil de cifrado de contraseñas de PHP¹². El sistema de permisos de WordPress se utiliza para controlar el acceso a información privada, como la información personal de los usuarios registrados, las direcciones de correo electrónico de los comentaristas, el contenido publicado de forma privada, etc. En WordPress 3.7, se incluyó un medidor de seguridad de contraseñas en el núcleo del software que proporciona información adicional a los usuarios que configuran sus contraseñas y consejos para aumentar la seguridad. WordPress también dispone de un ajuste de configuración opcional para exigir 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 nonces¹³, para validar la intención de las peticiones de acción de usuarios autorizados para protegerse de posibles amenazas CSRF. WordPress proporciona una API para la generación de estos tokens para crear y verificar tokens únicos y temporales, y el token se limita a un usuario específico, una acción específica, un objeto específico y un período de tiempo específico, que se puede añadir a los formularios y URLs según sea necesario. Además, todos los nonces se invalidan al cerrar la sesión.

A9 – Uso de componentes con vulnerabilidades conocidas

El equipo del núcleo de WordPress supervisa minuciosamente las pocas bibliotecas y frameworks incluidos con los que WordPress se integra para las funcionalidades básicas. En el pasado, el equipo del núcleo ha realizado contribuciones a varios componentes de terceros para hacerlos más seguros, como la actualización para solucionar una vulnerabilidad entre sitios en TinyMCE en WordPress 3.5.2.¹⁴.

En caso necesario, el equipo del núcleo puede decidir bifurcar o sustituir componentes externos críticos, como cuando la biblioteca SWFUpload fue sustituida oficialmente por la biblioteca Plupload en la versión 3.5.2, y el equipo de seguridad puso a disposición una bifurcación segura de SWFUpload.¹⁵ para los plugins que siguieron utilizando SWFUpload a corto plazo.

A10 – Redirecciones y envíos sin validar

El sistema interno de control de acceso e identificación de WordPress protegerá contra los intentos de dirigir a los usuarios a destinos no deseados o redireccionamientos automáticos. Esta funcionalidad también se pone a disposición de los desarrolladores de plugins a través de una API,, wp_safe_redirect()¹⁶.

Otros riesgos y problemas de seguridad

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

Al procesar XML, WordPress desactiva la carga de entidades XML personalizadas para prevenir ataques de entidad externa y expansión de entidad. Más allá de la funcionalidad principal de PHP, WordPress no proporciona una API de procesamiento XML segura adicional para 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 plugins y temas de 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-Three») 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.

Repositorios de temas y plugins de WordPress.org

Hay aproximadamente más de 50.000 plugins y más de 5.000 temas listados en el sitio WordPress.org. Estos temas y plugins son enviados para su inclusión y son manualmente revisados por voluntarios antes de estar disponibles en el repositorio.

La inclusión de plugins y temas en el repositorio no garantiza que estén libres de vulnerabilidades de seguridad. Los autores de los plugins pueden consultar las directrices antes de enviarlos para su inclusión en el repositorio.¹⁷, y hay una amplia documentación sobre cómo hacer desarrollo de temas WordPress¹⁸ disponible en el sitio WordPress.org.

Cada plugin y tema tiene la posibilidad de ser desarrollado continuamente por el propietario del plugin o tema y cualquier posterior corrección o desarrollo de características pueden ser subidas al repositorio y hacer que estén disponibles para los usuarios que tengan 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 ser actualizados a través de su 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, dirigido por miembros clave y consolidados de la comunidad de WordPress, que revisa y aprueba los temas enviados para su inclusión en el directorio oficial de temas de WordPress. El equipo de revisión de temas mantiene las directrices oficiales de revisión de temas.¹⁹, los datos de la unidad de prueba de temas²⁰, y los plugins de comprobación de temas²¹, e intenta involucrar y educar a la comunidad de desarrolladores de temas WordPress en aplicar buenas prácticas en el desarrollo de temas. La inclusión en el grupo está moderada por los compiladores principales del equipo de desarrollo de WordPress.

El perfil del proveedor de alojamiento en la seguridad de 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.

Nota acerca de WordPress.com y la seguridad de WordPress

WordPress.com es la mayor instalación de WordPress del mundo, y es propiedad y está gestionada por Automattic, Inc, fundada por Matt Mullenweg, cocreador del proyecto WordPress. WordPress.com funciona con el software principal de WordPress y tiene sus propios procesos, riesgos y soluciones de seguridad.²². Este documento se refiere a la seguridad relativa al software WordPress de código abierto, descargable y autoalojado, disponible en WordPress.org e instalable 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 consta de varias APIs individuales²³, y cada una cubre las funciones a las que está destinada, y para usarse en un conjunto dado de funcionalidades. Unidas, forman la interfaz del proyecto que permite que los plugins y los temas interactúen, alteren y amplíen la funcionalidad del núcleo de WordPress de manera limpia 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 base de datos²⁴, añadida en WordPress 0.71, ofrece el método correcto de acceso a datos como valores de nombres almacenados en la capa de la base de datos.

API del sistema de archivos

La API del sistema de archivos²⁵, añadida en WordPress 2.6²⁶, se creó originalmente para la característica de actualizaciones automáticas de. La API del sistema de archivos abstrae la funcionalidad necesaria para hacer que sea segura la lectura y escritura de archivos locales al sistema de archivos, en una gran variedad de tipos de servidor.

Lo hace a través de la clase WP_Filesystem_Base y varias subclases que implementan diferentes formas de conectarse al sistema de archivos local, dependiendo de la compatibilidad de cada servidor. Cualquier tema o plugin que necesite escribir archivos localmente debería hacerlo usando la familia de clases WP_Filesystem.

API HTTP

La API HTTP ²⁷, añadida en WordPress 2.7²⁸ y ampliada en WordPress 2.8, estandariza las peticiones HTTP para WordPress. La API gestiona cookies, cifrado y descifrado gzip, descifrado de trozos ( si es HTTP 1.1), y varias otras implementaciones del protocolo HTTP. La API estandariza las peticiones, prueba cada método antes de enviarlas y, basándose en la configuración de su servidor, utiliza el método apropiado para realizar la petición.

Permisos y la API del usuario actual

La API de permisos y usuario actual²⁹ es un conjunto de funciones que ayudarán a verificar los permisos y la autoridad del usuario actual para realizar cualquier tarea u operación que se solicite, y puede proteger aún más contra usuarios no autorizados que accedan o realicen 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 marca comercial) está licenciado bajo CC0 1.0 Universal (CC0 1.0) Dedicación al dominio público. Puedes copiar, modificar, distribuir y ejecutar la obra, incluso con fines comerciales, todo ello sin pedir permiso.

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