Seguridad

Esta página describe el modelo de seguridad de WebBlocks CMS y los pasos que debe seguir un operador. o agencia debería adoptar para ejecutarlo de forma segura en los sitios de los clientes. Para saber cómo reportar un vulnerabilidad, consulte SECURITY.md; no abra el archivo público problemas para los informes de seguridad.

Fortalecimiento de la implementación

Estos son los controles más importantes para una instalación de producción:

  • Sirve solo public/ como raíz web. La raíz de la aplicación contiene .env, .git, .github, storage/, vendor/ y el código fuente que debe nunca será accesible a través de la web. Apunte la raíz de su documento Nginx/Apache a public/ y confirme que https://your-site/.git/config y https://your-site/.env ambos devuelven 404. Se filtra un directorio .git expuesto su fuente completa y cualquier secreto comprometido.
  • Prefiera un artefacto de lanzamiento a un clon de git sin formato en producción. Lanzamiento Los paquetes excluyen .git, .github, project/ y otros archivos que no son de tiempo de ejecución. (ver reglas .gitattributes export-ignore). Si implementa un clon, desactívelo presione la instalación (git remote set-url --push origin DISABLED).
  • Set APP_DEBUG=false y un fuerte APP_KEY en producción. Modo de depuración filtra rastros de pila, valores de entorno y rutas internas.
  • Uuse HTTPS y configure SESSION_SECURE_COOKIE=true al publicar a través de TLS.
  • Permisos de archivo: el usuario web/PHP necesita lectura/escritura en storage/ y el Raíz del disco backups (predeterminado storage/app/backups). ¿not usa 777? otorgar propiedad o acceso de grupo en su lugar.
  • Guardar secretos en .env. .env, .env.* (excepto .env.example) y auth.json son ignorados por git. Los tokens API de CMS y las contraseñas de correo nunca son escrito en el repositorio.

Autenticación y autorización

  • La autenticación de CMS es nativa de Laravel (sin requisitos de Breeze/Jetstream/Fortify). Administradores inicie sesión en /webadmin/login; las contraseñas tienen hash bcrypt.
  • Acceso de puerta de tres roles de instalación: super_admin (toda la instalación), site_admin (sitios asignados) y editor (borrador de contenido dentro de los sitios asignados). Sitio cruzado acciones (mover/duplicar, Shared Slots) imponen el acceso tanto al origen como al destino sitios. Consulte Uusuarios y permisos.
  • El árbol de administración /webadmin está protegido por la web CMS + autenticación + acceso de administrador pila de middleware. Las rutas públicas nunca muestran contenido en borrador; borrador/vista previa el acceso requiere un administrador autenticado o un token confiable con content.read.
  • Las solicitudes de inicio de sesión y restablecimiento de contraseña tienen una velocidad limitada. Los inicios de sesión fallidos son limitado por correo electrónico+IP (por defecto, 5 intentos, luego un breve bloqueo que el inicio de sesión exitoso se borra; sintonizar con WEBBLOCKS_CMS_MAX_LOGIN_ATTEMPTS y WEBBLOCKS_CMS_LOGIN_DECAY_SECONDS). Un respaldo por IP también limita la puntos finales de inicio de sesión, contraseña olvidada y restablecimiento de contraseña contra inundaciones y intentos de rotación de correo electrónico.

Internal Content API

El Internal Content API (/webadmin/api) es para operadores confiables/herramientas de IA.

  • Los tokens personales los crea cualquier usuario activo de CMS desde Profile → Personal Fichas API; Los tokens del sistema a nivel de instalación son creados por un super_admin de Sistema → Tokens API. Ambos se almacenan como hash y se muestran en formato simple. texto solo una vez.
  • Cada token lleva capacidades explícitas (lectura, publicación, medios, complemento ciclo de vida, comercio,…). Las capacidades avanzadas/destructivas son opciones de suscripción independientes; Las capacidades normales de creación de páginas son las predeterminadas.
  • Los tokens pueden ser revocados (manteniendo la fila de auditoría) o eliminados. Un por token El registro de actividad registra el tiempo, método/ruta, ruta, resultado de capacidad, IP y un resumen de agente de usuario, pero nunca solicite cuerpos, cadenas de consulta, respuestas o valores simbólicos.
  • Trate los tokens API como secretos. Alcancelos hasta las capacidades mínimas de una herramienta. necesidades y rotarlos si están expuestos.
  • Los tokens de API personales se cruzan continuamente con capacidades y sitios seleccionados con la función en vivo, el estado activo, las asignaciones de sitio y la página de su propietario autoridad del flujo de trabajo. Las operaciones a nivel de instalación siguen siendo solo token del sistema.
  • Los tokens de API personales se pueden restringir a direcciones IPv4/IPv6 o CIDR exactas redes y tienen un límite de solicitud por minuto específico de token. Estos controles se aplican además del usuario en vivo, el sitio, el flujo de trabajo y el acceso a capacidades.
  • Tanto las rutas canónicas /webadmin/api como la heredada /admin-api Las rutas de compatibilidad comparten el limitador de velocidad Internal Content API.

Cuando hay un proxy inverso o CDN, configure Laravel para confiar solo en el direcciones de proxy reales y verificar la IP del cliente resuelta antes de habilitar una lista de permitidos. Nunca acepte encabezados reenviados falsificados directamente desde Internet.

Consulte Tokens API personales y Internal Content API.

Actualizar seguridad

Las actualizaciones del sistema en la aplicación reemplazan el código del paquete CMS en vendor/fklavyenet/webblocks-cms en el sitio en vivo. Porque una actualización ejecuta nueva código, la integridad del paquete descargado es una ejecución de código remoto límite. WebBlocks CMS mitiga esto de la siguiente manera:

  • Suma de comprobación obligatoria SHA-256. El actualizador descarga el archivo ZIP de la versión y luego verifica hash_file('sha256', …) con el checksum_sha256 proporcionado por el publicar metadatos utilizando un hash_equals de sincronización segura. Si falta la suma de verificación o no coincide, la actualización es refused: no vuelve a aplicando un paquete no verificado.
  • Servicio de actualización canónico. Los metadatos de actualización y las descargas provienen de publisher.webblocksui.com. Debido a que la suma de control se entrega junto con el descarga por el mismo servicio, la suma de comprobación protege contra datos corruptos o artifacts manipulado, pero no contra un servicio de actualización totalmente comprometido.
  • Las instalaciones son consumidores, no editores. Los sitios instalados obtienen actualizaciones pero no debe enviarse al repositorio ascendente. La publicación se realiza únicamente desde el verificación de mantenimiento con un WEBBLOCKS_PUBLISHER_TOKEN.

Verificación de firma (Ed25519)

Para una defensa en profundidad contra un servicio de actualización comprometido: donde se encuentra la suma de verificación viaja junto al artefacto: las versiones pueden estar firmadas criptográficamente . El editor firma la suma de verificación de liberación con una clave secreta Ed25519 e instala verificar la firma con una clave pública fijada (sodium_crypto_sign), por lo que La instalación rechaza cualquier versión no firmada por la clave real.

Para habilitarlo:

  1. Genere un par de claves una vez, en la máquina de mantenimiento/editor: php artisan webblocks:updates:keygen.
  2. Mantenga privado el WEBBLOCKS_PUBLISHER_SIGNING_KEY impreso (secreto): configúrelo solo donde publicas lanzamientos. Nunca lo confirmes ni lo configures en una instalación.
  3. Fije la clave pública impresa para que las instalaciones verifiquen las versiones firmadas: configurar WEBBLOCKS_UPDATE_PUBLIC_KEY, o configure ReleaseDefaults::UPDATE_PUBLIC_KEY de modo que La clave se envía en el código CMS (recomendado: no se puede utilizar una clave con código fijo). intercambiado a través de un .env comprometido).
  4. Publicar como de costumbre; el editor firma cada versión automáticamente.

Rollout es seguro: aunque no se fija ninguna clave pública, la verificación de firma no lo es (aún se aplica la verificación de suma de verificación). Una vez que se fija una clave pública y las instalaciones reciben ese código, cada versión futura debe llevar un Ed25519 válido firma sobre su suma de verificación, o se rechaza la actualización.

Seguridad de contenidos y entradas

  • Formularios públicoscompartir un canal de protección local: prueba firmada encuadernada con un formulario, honeypots generados, sincronización, puntuación de contenido/repetición, remitente y fuente clave contadores,/24o/64presión de la red y huellas digitales aprendidas en el sitio local. No hace ninguna petición externa. Los contadores de protección utilizan hashes con clave; métricas diarias contienen únicamente decisiones agregadas. VerEnvío público Protección.
  • Formularios de contactoalmacene los envíos calificados para su revisión. Cuarentena y supresión de spam notificación sin dejar de estar separado del historial de entrega de notificaciones. VerFormularios de contacto y mensajes.
  • Comentariospredeterminado apending; una decisión de spam se conserva como spam y nunca Aparece públicamente sin moderación.
  • Confiable HTMLse limita al marcado de diseño adyacente al contenedor y no debe utilizado para inyectar guiones; prefieren los contratos de bloque nativos, que el Interno La API de contenido valida primero el borrador.
  • Las cargas de medios están restringidas a una lista permitida de imágenes, videos y documentos. tipos(contenido olfateado, no extensión confiable).Las cargas SVG están deshabilitadas por defecto, porque un SVG puede llevar script en línea y los medios se sirven desde El mismo origen que el administrador. Habilítelo solo en instalaciones donde cada cuenta que puede cargar medios es confiable, a través deWEBBLOCKS_CMS_ALLOW_SVG_UPLOADS=true. La misma lista de permitidos rige las recuperaciones de medios remotos del lado del servidor.
  • La recuperación remota de medios valida cada objetivo de redireccionamiento y fija el HTTP conexión a la dirección IP pública que pasó la validación.Esto cierra el Carrera de conexión/búsqueda de DNS utilizada por ataques de revinculación de DNS. Obtención remota falla al cerrarse cuando la fijación de dirección cURL PHP no está disponible.
  • Los iframes de aplicaciones integradas administradas son entornos limitados de origen opaco.Su las respuestas de entrada aplican CSP restrictivos y encabezados de referencia. CSP nombra el origen del sitio registrado actual explícitamente para que se puedan cargar documentos de origen opaco sus guiones, estilos, medios y contenidos del mismo sitio.<base>URL sin otorgar el iframe acceso del mismo origen a las cookies de CMS, al almacenamiento, a la página principal o solicitudes de panel autenticadas.
  • Los paquetes completos de aplicaciones integradas permanecen aislados.inmutable, Los archivos de paquetes versionados se entregan a través de una ruta pública exclusiva de la aplicación. con CORS anónimo y encabezados de recursos de origen cruzado, lo que permite el origen opaco juegos para cargar imágenes, audio, fuentes, JSON y archivos locales sin otorgarallow-same-origin. La instalación ZIP rechaza recorridos transversales, duplicados, archivos ejecutables del servidor y violaciones de recuento limitado o tamaño ampliado.

Telemetría y privacidad

  • Las comprobaciones de actualización pueden enviar telemetría de adopción para preservar la privacidad al editor: solo product_key, installed_version, channel, un aleatorio persistido localmente installation_id y telemetry_schema_version. Sin dominios, URL, administrador correos electrónicos, rutas, detalles de la base de datos, recuentos de usuarios, tokens o entorno/configuración arbitrarios Se envían los valores. Configure WEBBLOCKS_TELEMETRY=false para optar por no participar; comprobaciones de metadatos continuar sin una instalación ID.
  • Los informes de visitantes conservan registros de vistas de página con ruta, hora y referencia normalizada host, valores UTM, categoría de dispositivo y clasificación de bot. Completo basado en el consentimiento el seguimiento también puede conservar una clave de sesión y una IP HMAC; estos son seudónimos identificadores, no una garantía de anonimato. Nuevos gráficos y modales de detalles de página. no introduzca identificadores adicionales ni scripts de seguimiento públicos. Programado la retención reemplaza los detalles caducados con recuentos diarios de sitio/localización y posteriores caduca esos conteos. Ver Operaciones.

Informar de una vulnerabilidad

Reportar de forma privada a través de GitHub Security Advisories o el contacto del mantenedor en SEGURIDAD.md. Nuestro objetivo es reconocer informes dentro de 5 negocios. días y coordinaremos un cronograma de divulgación con usted.

Inicio y recuperación del complemento (1.94.0–1.94.2)

La instalación, actualización y activación del complemento administrado por CMS validan el candidato en un proceso PHP separado antes de la activación en tiempo de ejecución normal. La fuente no válida, las fallas del proveedor/ruta, las salidas anticipadas y los tiempos de espera lo rechazan; una actualización rechazada conserva el paquete de trabajo. Las fallas en la configuración de la base de datos mantienen el complemento deshabilitado y preservan sus datos. Las fallas de ruta o fuente de tiempo de ejecución ponen en cuarentena el complemento afectado y eliminan las rutas parcialmente registradas.

La pantalla /webadmin/plugin-recovery y el inicio de sesión se cargan sin la fuente del complemento instalado. CMS 1.94.2 aplica acceso de administrador de cuenta activa y autorización Super admin, incluidas las sesiones existentes. La recuperación puede deshabilitar el complemento defectuoso o restaurar el paquete anterior retenido solo cuando no se ejecutó ninguna migración de la base de datos; La restauración repite la validación de inicio y vuelve a publicar los activos anteriores. Los controles de inicio de sesión normales y la protección CSRF siguen vigentes. Esto protege la ruta de recuperación del complemento administrado, no los proveedores de host arbitrarios ni el aislamiento del ejecutable PHP. Consulte Sistema de complementos.

Autoridad API de actualizaciones del sistema (1.90.0)

Las actualizaciones de instalación requieren un token del sistema para toda la instalación propiedad de un usuario activo con acceso al sistema. system-updates.read y system-updates.run son opciones de suscripción independientes; ni los tokens personales ni los tokens de ámbito del sitio pueden usarlos. La ejecución requiere la aprobación explícita de la versión instalada, la versión de destino y la suma de verificación, con un recibo de idempotencia duradero para respuestas inciertas. Ver Actualizaciones.