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 apublic/y confirme quehttps://your-site/.git/configyhttps://your-site/.envambos devuelven 404. Se filtra un directorio.gitexpuesto 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.gitattributesexport-ignore). Si implementa un clon, desactívelo presione la instalación (git remote set-url --push origin DISABLED). - Set
APP_DEBUG=falsey un fuerteAPP_KEYen producción. Modo de depuración filtra rastros de pila, valores de entorno y rutas internas. - Uuse HTTPS y configure
SESSION_SECURE_COOKIE=trueal publicar a través de TLS. - Permisos de archivo: el usuario web/PHP necesita lectura/escritura en
storage/y el Raíz del discobackups(predeterminadostorage/app/backups). ¿not usa777? otorgar propiedad o acceso de grupo en su lugar. - Guardar secretos en
.env..env,.env.*(excepto.env.example) yauth.jsonson 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) yeditor(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
/webadminestá 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 concontent.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_ATTEMPTSyWEBBLOCKS_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_adminde 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/apicomo la heredada/admin-apiLas 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 elchecksum_sha256proporcionado por el publicar metadatos utilizando unhash_equalsde 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:
- Genere un par de claves una vez, en la máquina de mantenimiento/editor:
php artisan webblocks:updates:keygen. - Mantenga privado el
WEBBLOCKS_PUBLISHER_SIGNING_KEYimpreso (secreto): configúrelo solo donde publicas lanzamientos. Nunca lo confirmes ni lo configures en una instalación. - Fije la clave pública impresa para que las instalaciones verifiquen las versiones firmadas: configurar
WEBBLOCKS_UPDATE_PUBLIC_KEY, o configureReleaseDefaults::UPDATE_PUBLIC_KEYde 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.envcomprometido). - 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 a
pending; 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 de
WEBBLOCKS_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 otorgar
allow-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 localmenteinstallation_idytelemetry_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. ConfigureWEBBLOCKS_TELEMETRY=falsepara 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.