Seguridad

Aprende más sobre la seguridad del núcleo de Software de WordPress en este libro blanco gratis. También puedes descargarlo en Formato PDF.

Informació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 en este documento está actualizada para la última versión estable del software, WordPress 4.7 en el momento de la publicación, pero debe ser considerado relevante también a las versiones más recientes del software como compatibilidad inversa es un fuerte enfoque para el Equipo de desarrollo de WordPress. Se notificarán las medidas y cambios de seguridad específicos, mientras se vayan añadiendo al software principal en versiones específicas. Se recomienda encarecidamente que siempre se ejecute 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 contenido dinámico de código abierto, que se utiliza para alimentar millones de sitios web, aplicaciones web y blogs. Actualmente potencia más de 42% de los principales 10 millones sitios web en Internet. La usabilidad, la extensibilidad y la comunidad de desarrollo maduro de WordPRess hacen que sea una opción popular y segura para sitios web de todos los tamaños.

Desde su creación en 2003, WordPress ha experimentado un endurecimiento continuo por lo que su software principal puede abordar y mitigar las amenazas comunes de seguridad, incluyendo la lista de los 10 problemas identificados por el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP) como vulnerabilidades comunes de seguridad, las que se discuten en este documento.

El equipo de seguridad de WordPress, en colaboración con El Equipo de Liderazgo del Núcleo, y respaldado por la comunidad global de WordPress, trabaja para identificar y resolver problemas de seguridad en el software básico disponible para la distribución y la instalación en WordPress.org, además de recomendar y documentar las mejores prácticas de seguridad para plugins y autores de temas de terceros.

Los desarrolladores y administradores del sitio deben prestar especial atención al uso correcto de APIs básicas y a la configuración subyacente del servidor que hayan sido la fuente de vulnerabilidades comunes, así como asegurar que todos los usuarios empleen 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 software CMS más utilizado en el mundo y potencia más de42% de los principales 10 millones sitios web1, dándole una cuota de mercado estimada62% de todos los sitios utilizando 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. Tienes la libertad de usar el programa, para cualquier propósito.
  2. La libertad de estudiar cómo funciona el programa, y ​​cambiarlo para que haga lo que usted desea.
  3. La libertad de redistribuir.
  4. La libertad de distribuir copias de sus versiones modificadas a otras.

El Equipo de Liderazgo del Núcleo de WordPress

El proyecto WordPress es una meritocracia, dirigida por un equipo de liderazgo principal, y liderada por su co-creador y desarrollador principal, Matt Mullenweg. El equipo gobierna todos los aspectos del proyecto, incluyendo el desarrollo básico, la WordPress.org, y las iniciativas comunitarias.

El Equipo de Liderazgo del Núcleo está conformado por Matt Mullenweg, cinco desarrolladores principales, y más de una docena de desarrolladores centrales con acceso permanente a commit. Estos desarrolladores tienen autoridad final en las decisiones técnicas, y lideran discusiones de arquitectura y esfuerzos de implementación.

WordPress tiene una serie de desarrolladores contribuyentes. Algunos de ellos son committers anteriores o actuales, y algunos son futuros committers. Estos desarrolladores contribuyentes son colaboradores de confianza y veteranos de WordPress que han ganado una gran cantidad de respeto entre sus compañeros. Según sea necesario, WordPress también cuenta con committers invitados, individuos a los que se les concede el acceso de commit, a veces para un componente específico, de forma temporal o de prueba.

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 Lanzamiento 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 Lanzamientos 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 de Seguridad, Procesos e Historia de 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 Lanzamientos 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 eliminar actualizaciones en segundo plano a través de un simple cambio en su archivo de configuración, pero mantener la funcionalidad es muy recomendable por el equipo central, así como ejecutar la última versión estable de WordPress.

Top 10 OWASP 2013

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 discuten las API, los recursos y las políticas que utiliza WordPress para fortalecer el software principal y los plugins y temas de terceros en contra de estos riesgos potenciales.

A1 - Inyección

Hay un conjunto de funciones y APIs disponibles en WordPress para ayudar a los desarrolladores a asegurarse de que no se pueda inyectar código no autorizado, y así ayudarlos a validar y desinfectar los datos. Las mejores prácticas y documentación están disponibles9 pasa saber cómo utilizar estas API para proteger, validar o higienizar los datos de entrada y salida en HTML, URLs, encabezados 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 se pueden cargar mediante filtros.

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

El software Core de WordPress administra las cuentas de usuario y la autenticación, y los detalles como el ID, nombre y contraseña son gestionados en el servidor, así como las cookies de autenticación. Las contraseñas están protegidas en la base de datos utilizando técnicas estándar de salazón y estiramiento. Las sesiones existentes se destruyen al cerrar la sesión para las versiones de WordPress después de 4.0.

A3 - Cross Site Scripting (XSS)

WordPress proporciona una gama de funciones que pueden ayudar a asegurar que los datos suministrados por el usuario son seguros 10. Los usuarios de confianza, que son administradores y editores en una sola instalación de WordPress, y los administradores de red sólo en WordPress Multi sitio, pueden publicar HTML o JavaScript sin filtrar como lo necesites, como dentro de una entrada o página. Los usuarios no confiables y el contenido enviado por el usuario se filtran de forma predeterminada para eliminar entidades peligrosas, utilizando la biblioteca KSES a través de la función wp_kses.

Como ejemplo, el equipo Core de WordPress notó antes de la versión 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 estaban escapando de la salida de la función para su uso en HTML. En un caso muy raro de compatibilidad ligeramente hacia atrás, la salida de la función se modificó en WordPress 2.3 para ser pre-escapada.

A4 - Referencia Directa de Objeto Inseguro

WordPress suele proporcionar referencias directas de objetos, como identificadores numéricos únicos de cuentas de usuario o contenido disponibles en los campos URL o formulario. Si bien estos identificadores revelan información directa del sistema, los permisos enriquecidos y el sistema de control de acceso de WordPress previenen las solicitudes no autorizadas.

A5- Configuración Errónea de Seguridad

La mayoría de las operaciones de las configuraciones de seguridad de WordPress están limitadas a un único administrador autorizado. Los ajustes predeterminados para WordPress son continuamente evaluados a nivel de equipo central, y el equipo de WordPress Core proporciona documentación y mejores prácticas para apretar la seguridad de la configuración del servidor para ejecutar un sitio de 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 - Control de Acceso a Funciones sin el Nivel Correspondiente

WordPress comprueba la autorización y los permisos apropiados para cualquier solicitud de acceso a nivel de función antes de la acción que se está ejecutando. El acceso o la visualización de URLs, menús y páginas administrativas sin la autenticación adecuada está estrechamente integrado con el sistema de autenticación para impedir el acceso de usuarios no autorizados.

A8 - Falsificación de Solicitudes Cruzadas (CSRF)

WordPress utiliza tokens criptográficos, llamados nonces13, para validar la intención de las peticiones de acción de usuarios autorizados para protegerse contra posibles amenazas CSRF. WordPress proporciona una API para la generación de estos tokens con le objetivo de 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 se puede agregar a 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 Core de WordPress monitorea estrechamente las pocas bibliotecas y frameworks incluidos con los que se integra WordPress para funcionalidades básicas. En el pasado el equipo central ha hecho contribuciones a varios componentes de terceros para que sean más seguros, como la actualización para fijar una vulnerabilidad entre sitios en TinyMCE en WordPress 3.5.2 14.

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 puesto a disposición por el equipo de seguridad<15 para aquellos plugins que siguieron usando SWFUpload a corto plazo.

A10 - Redirecciones y Forwards No Validados

El sistema de control y autenticación de acceso interno de WordPress protegerá contra los intentos de dirigir a los usuarios a destinos no deseados o a redirecciones automáticas. Esta funcionalidad también se pone a disposición de los desarrolladores de plugins a través de una API, wp_safe_redirect() 16.

Otros Riesgos y Preocupaciones de Seguridad

Procesamiento de Ataques XXE (Entidad Externa XML)

Al procesar XML, WordPress deshabilita la carga de entidades XML personalizadas para evitar los ataques de expansión de entidad externa y entidad. Más allá de la funcionalidad principal de WordPress no proporciona una API de procesamiento XML segura adicional para los autores de plugins.

Ataques SSRF (Falsificación de la Petición del Lado del Servidor)

Las solicitudes HTTP emitidas por WordPress se filtran para impedir el acceso a las direcciones de bucle e IP privadas. Además, el acceso sólo se permite a ciertos puertos HTTP estándar.

Seguridad de los Plugin y Temas de WordPress

El Tema por Defecto

WordPress requiere que un tema sea habilitado para renderizar el contenido visible en el frontend. El tema por defecto que se envía con Core WordPress (actualmente "Twenty Twenty-One") 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 predeterminado puede servir como punto de partida para el desarrollo de temas personalizados, y los desarrolladores de sitios pueden crear un tema secundario que incluya cierta personalización, pero que recaiga en el tema predeterminado para la mayoría de las funcionalidades y la seguridad. El tema predeterminado puede ser eliminado fácilmente por un administrador si no es necesario.

Repositorio de Temas y Plugins de WordPress.org

Hay aproximadamente50,000 + plugins y5,000 + temas listados en el sitio WordPress.org. Estos temas y plugins se envían para su inclusión y son revisados manualmente por voluntarios antes de hacerlos disponibles en el repositorio.

La inclusión de plugins y temas en el repositorio no es una garantía de que estén libres de vulnerabilidades de seguridad. Se proporcionan pautas para que los autores de plugins consulten antes de la presentación para su inclusión en el repositorio17, y además se proporciona en el sitio WordPress.org una amplia documentación sobre cómo hacer el desarrollo del tema de WordPress 18.

Cada plugin y tema tiene la capacidad de ser continuamente desarrollado por su propietario, y cualquier correccion subsecuentes o desarrollo de características pueden ser subidos al repositorio y disponibilizado para permitir a los usuarios que tengan dicho plugin o tema instalado con la descripción de ese Cambio. Los administradores del sitio son notificados de los plugins que necesitan ser actualizados mediante su tablero de la administración.

Cuando el equipo de seguridad de WordPress descubre una vulnerabilidad de plugin, se comunican con el autor del plugin y trabajan juntos para fijar 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 o Tema es sacado del directorio publico, 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, liderados por miembros clave y establecidos de la comunidad WordPress, quienes revisan y aprueban temas presentados para ser incluidos en el Directorio de Temas oficial de WordPress. El equipo de revisión de temas mantiene las Pautas Oficiales de Revisión de Temas19, los Test Unitarios para los Temas20, y el Chequeo de Plugins de Temas 21, además de los intentos de participar y educar a la comunidad de desarrolladores de temas de WordPress sobre 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 Rol del Proveedor de Hosting en la Seguridad de WordPress

WordPress se puede instalar en una multitud de plataformas. Aunque el software de WordPress Core proporciona muchas provisiones para operar una aplicación web segura, que se cubrieron en este documento, la configuración del sistema operativo y el servidor Web subyacente que aloja el software es igualmente importante para mantener seguras las aplicaciones de WordPress.

Una nota sobre la seguridad de WordPress.com y WordPress

WordPress.com es la mayor instalación de WordPress en el mundo, y es propiedad y gestionada por Automattic, Inc., que fue fundada por Matt Mullenweg, el co-creador del proyecto de WordPress. WordPress.com se ejecuta en el software básico de WordPress, y tiene sus propios procesos de seguridad, riesgos y soluciones22. Este documento se refiere a la seguridad con respecto a la auto-alojado, descargable software de código abierto de WordPress disponible en WordPress.org e instalable en cualquier servidor en el mundo.

Apéndice

APIs del Núcleo de WordPress

El Núcleo de las Interfaces de Programación de Aplicaciones (API) de WordPress está compuesta por varias API individuales 23, cada una cubriendo las funciones involucradas en, y el uso de, un conjunto dado de funcionalidad. Juntos, éstos forman la interfaz del proyecto que permite que los plugins y los temas interactúen, alteren, y amplíen la funcionalidad básica de WordPress de forma segura y segura.

Mientras que cada API de WordPress proporciona las mejores prácticas y formas estandarizadas para interactuar con WordPress Core y ampliar el software, las siguientes API de WordPress son las más pertinentes para la aplicación y endurecimiento de la seguridad de WordPress:

API de Base de datos

La API de base de datos 24, agregada en WordPress 0.71, proporciona el método correcto para acceder a los datos como valores con nombre que se almacenan en la capa de base de datos.

API Filesystem

LA API filesystem 25, agregadA en WordPress 2.626, fue creado originalmente para las funciones propias de WordPress respecto a las actualizaciones automáticas. La API de filesystem abstrae la funcionalidad necesaria para leer y escribir archivos locales en el sistema de archivos que se realizará de forma segura, en una variedad de tipos de hosts.

Lo hace a través de la clase WP_Filesystem_Base, y varias subclases que implementan diferentes maneras de conectarse al sistema de archivos local, dependiendo del soporte de host individual. Cualquier tema o plugin que necesite escribir archivos localmente debe hacerlo usando la familia de clases WP_Filesystem.

API HTTP

La API HTTP 27, agregada en WordPress 2.728 y ampliado en WordPress 2.8, estandariza las peticiones HTTP para WordPress. La API maneja cookies, codificación gzip y descodificación, descodificación de fragmentos (si es HTTP 1.1), y varias implementaciones de protocolos HTTP. La API estandariza las solicitudes, comprueba cada método antes del envío y, basándose en la configuración del servidor, utiliza el método apropiado para realizar la solicitud.

Permisos y API de usuario actual

Los permisos y la API de usuario actual 29 es un conjunto de funciones que ayudarán a verificar los permisos y la autoridad actuales del usuario actual para realizar cualquier tarea o 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 contenido del papel 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) Public Domain Dedication. Tú puedes copiar, modificar, distribuir y realizar el trabajo, incluso con fines comerciales, todo sin pedir permiso.

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

Lectura Adicional

Creado por Sara 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 al pie