Seguridad

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

Vista previa

Este documento es un análisis y explicación del desarrollo del núcleo del software 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 la toma de decisiones que evalúan WordPress como sistema de gestión de contenidos o entorno de trabajo para aplicaciones web deben 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.7 a la fecha de su publicación, pero debe ser considerada relevante también para 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 núcleo del software 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 43% de los principales 10 millones de webs en Internet. La usabilidad, extensibilidad y madura comunidad de desarrollo de WordPress hace que sea una segura elección para las webs de todos los tamaños.

Desde su inicio en el 2003, WordPress se ha fortalecido continuamente para que 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 por sus siglas en inglés The Open Web Application Security Project) 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 43% 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á licenciado bajo la Licencia Pública General (GPLv2 o posterior) que proporciona cuatro libertades fundamentales, y puede ser considerado como la“Declaración de Derechos” de WordPress:

  1. Libertad de ejecución del programa, para cualquier propósito.
  2. Libertad para estudiar el funcionamiento del programa, y cambiarlo para que haga lo que usted desee.
  3. Libertad para redistribuir.
  4. La libertad para distribuir copias de sus 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 principales y contribuyentes son quienes primariamente guían el desarrollo de WordPress. En cada versión, cientos de desarrolladores aportan código a WordPress. Estos colaboradores principalmente son voluntarios que contribuyen al código base de alguna manera.

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. Se detiene el proceso de 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 dañar la compatibilidad con versiones anteriores, WordPress trata de nunca dañar 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, 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.

Para 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 de Objeto Inseguro

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.

Errores en la 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 - Exposición de Datos Sensibles

Las contraseñas de la cuenta de usuario de WordPress son modificadas y hasheadas basadas en el Framework Portable de PHP de Hashing de Contraseñas12. El sistema de permisos de WordPress se utiliza para controlar el acceso a la información privada como usuarios registrados, ’PII, comentaristas ’ correo electrónico direcciones, contenido publicado en privado, etc. En WordPress 3.7, se incluyó un medidor de fuerza de contraseña en el software principal que proporciona información adicional a los usuarios estableciendo sus contraseñas y sugerencias sobre la fuerza creciente. WordPress también tiene un ajuste de configuración opcional 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 las solicitudes de intención de acción de los usuarios autorizados para protegerse contra 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 está limitado a un usuario específico, una acción específica, un objeto específico y un período de tiempo específico, que puede ser añadido a formularios y URLs según sea necesario. Además, todos los puntos se invalidan al cerrar la sesión.

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 el 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 es necesario, el equipo central puede decidir bifurcar o reemplazar componentes externos críticos, como cuando la biblioteca de SWFUpload fue reemplazada oficialmente por la biblioteca Plupload en 3.5.2, y una bifurcación segura de SWFUpload fue puesta a disposición por el equipo de seguridad<15 para aquellos plugins que siguieron usando SWFUpload a corto plazo.

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.

Otros Riesgos y Preocupaciones en Materia de Seguridad

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

Al procesar 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 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 temas y plugins WordPress

El tema predeterminado

WordPress requiere que un tema sea habilitado para renderizar el contenido visible en la portada. El tema por defecto que se envía con Core WordPress (actualmente "Twenty Twenty-Four") ha sido revisado y probado vigorosamente por razones de seguridad tanto por el Equipo de Desarrolladores de Temas más el equipo de desarrollo principal.

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 capacidad de ser desarrollado continuamente por el propietario del plugin o tema, y cualquier arreglo o desarrollo de características subsiguiente puede ser cargado en el repositorio y puesto a disposición de los usuarios con ese plugin o tema instalado con una descripción de ese cambio. Los administradores del sitio son notificados de los plugins que necesitan ser actualizados a través de su panel de administración.

Cuando el equipo de seguridad de WordPress descubre una vulnerabilidad del plugin, se ponen en contacto con el autor del plugin y trabajan juntos para arreglar y liberar una versión segura del plugin. Si hay una falta de respuesta del autor del plugin o si la vulnerabilidad es severa, el plugin/tema es retirado del directorio público, y en algunos casos, arreglado y actualizado directamente por 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 establecidos de la comunidad de WordPress, que revisan y aprueban los temas presentados para ser incluidos en el directorio oficial de Temas de WordPress. El Equipo de Revisión de Tema mantiene las Directrices oficiales de Revisión de Tema19, los Datos de Prueba de Unidad de Tema20, y los Plugins de Revisión de Tema21, e intenta involucrar y educar a la comunidad de desarrolladores de Tema de WordPress con respecto a las mejores prácticas de desarrollo. La inclusión en el grupo es moderada por los principales committers del equipo de desarrollo de WordPress.

El papel del proveedor de alojamiento en la seguridad de WordPress

WordPress puede ser instalado en una multitud de plataformas. Aunque el software principal de WordPress proporciona muchas provisiones para operar una aplicación web segura, las cuales fueron cubiertas en este documento, la configuración del sistema operativo y el servidor web subyacente que alberga el software es igualmente importante para mantener seguras las aplicaciones de WordPress.

Una nota sobre WordPress.com y la seguridad de WordPress

WordPress.com es la instalación de WordPress más grande del mundo, y es propiedad de Automattic, Inc. que fue fundada por Matt Mullenweg, el co-creador del proyecto WordPress. WordPress.com se ejecuta en el núcleo del software WordPress, y tiene sus propios procesos de seguridad, riesgos y soluciones22. Este documento se refiere a la seguridad del software de código abierto de WordPress, autohospedado y descargable, disponible en WordPress.org e instalable en cualquier servidor del mundo.

Apéndice

Core WordPress APIs

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.

Mientras que cada API de WordPress proporciona las mejores prácticas y formas estandarizadas de interactuar y ampliar el software central de WordPress, las siguientes APIs de WordPress son las más pertinentes para reforzar y endurecer la seguridad de WordPress:

API de la Base de Datos

El API24 de la base de datos, añadida en WordPress 0.71, proporciona el método correcto para acceder a los datos como valores nombrados que se almacenan en la capa de base de datos.

API de Sistemas de Archivos

La API de Sistemas de Archivos25, añadido en WordPress 2.626, fue creado originalmente para WordPress’ característica de actualizaciones automáticas propias. La API de Sistemas de Archivos abstrae la funcionalidad necesaria para leer y escribir archivos locales en el sistema de archivos de forma segura, en una variedad de tipos de host.

Lo hace a través de la clase WP_Filesystem_Base, y varias subclases que implementan diferentes formas de conexión al sistema de archivos local, dependiendo del soporte individual del host. Cualquier tema o plugin que necesite escribir archivos localmente debe hacerlo usando 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 para WordPress. La API maneja cookies, codificación y decodificación gzip, decodificación chunk (si HTTP 1.1), y varias otras implementaciones de protocolo HTTP. La API estandariza las solicitudes, prueba cada método antes de enviarlas y, en función de la configuración de su servidor, utiliza el método adecuado para realizar la solicitud.

Permisos y API de usuario actual

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

Licencia de contenido de libro blanco

El texto de este documento (sin incluir el logotipo de WordPress o la marca registrada) está licenciado bajo CC0 1.0 Universal (CC0 1.0) Dedicación de Dominio Público. Usted puede copiar, modificar, distribuir y realizar el trabajo, incluso con fines comerciales, todo ello sin pedir permiso.

Un agradecimiento especial a Drupal; s papel blanco de seguridad, que proporcionó algo de inspiración.

Lectura

Escrito porSara Rosso

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

Versión 1.0 Marzo 2015

Notas a pie de página