Documento técnico sobre seguridad y privacidad (resumen)Capítulo 11

Capítulo 11: Divulgación de vulnerabilidades y actualizaciones de seguridad

FileBolt fomenta la divulgación responsable y genera confianza con mecanismos de corrección y comunicación predecibles. Al mismo tiempo, las capacidades de seguridad deben poder evolucionar: incluidas las políticas de seguridad web, los mecanismos de autenticación del servidor y las implementaciones del cifrado de extremo a extremo y de los protocolos (p. ej., las actualizaciones de cryptoVersion). Este capítulo describe los canales de contacto públicos, los flujos de tramitación y los principios de publicación y comunicación de las correcciones, y explica las estrategias de evolución por versiones y de retirada.

11.0 Resumen

DEBE: ofrecer canales públicos para el envío de vulnerabilidades (p. ej., security.txt y un correo electrónico de soporte).
DEBERÍA: ofrecer mecanismos de envío cifrados (p. ej., una clave PGP) para enviar los detalles de forma segura.
DEBERÍA: definir un ritmo claro de respuesta y corrección (SLA u objetivos de plazo) y comunicarlo a través de la página de estado cuando sea necesario.
DEBE: tratar como máxima prioridad las vulnerabilidades que puedan afectar a los compromisos de conocimiento cero (XSS, inyección en la cadena de suministro, filtración de fragmentos en los registros).
DEBE: implementar una evolución versionada (cryptoVersion) y definir estrategias de compatibilidad, migración y retirada.

11.1 Canales de envío de vulnerabilidades y contacto

11.1.1 Puntos de entrada públicos

DEBE: indicar en /.well-known/security.txt los canales de envío de vulnerabilidades, la fecha de caducidad y los enlaces a las políticas.
DEBE: ofrecer un correo electrónico de contacto de seguridad al que se pueda escribir (p. ej., support@filebolt.net o uno específico, security@filebolt.net).
DEBERÍA: ofrecer instrucciones breves y pautas de envío en la página de Seguridad y privacidad.

11.1.2 Envío cifrado y tratamiento de información sensible

DEBERÍA: ofrecer una clave pública PGP (o equivalente) para que los investigadores envíen los detalles de reproducción de forma segura.
DEBE: aplicar internamente el mínimo privilegio de visibilidad a los detalles de las vulnerabilidades, revelándolos solo al personal necesario para la corrección.
DEBE: prohibir que los investigadores incluyan en los informes texto plano de usuarios, CEK, fragmentos de URL o material de claves derivable; si se incluye por error, el equipo DEBE tratarlo como un incidente sensible y limitar su difusión.

11.2 Plazos de respuesta y principios de comunicación

Los plazos dependen del tamaño y la complejidad del equipo, pero el proyecto DEBERÍA ofrecer un ritmo de objetivos predecible y comunicarlo con prontitud si no se cumplen. Objetivos recomendados (ajustables a la realidad y publicados en /security o en security.txt):

Primera respuesta: p. ej., acusar recibo y asignar un ID de seguimiento en un plazo de 48 horas.
Evaluación inicial: p. ej., completar la clasificación de gravedad y la evaluación del alcance del impacto en un plazo de 7 días.
Publicación de la corrección: avance según la gravedad; los P0/P1 tienen prioridad para una corrección y publicación rápidas.

DEBERÍA: mantener la comunicación necesaria durante la tramitación (p. ej., reproducida/no reproducida, se necesita más información, ventana estimada de corrección) y evitar divulgar públicamente detalles explotables.

11.3 Proceso de divulgación

Recepción: registrar los datos del informe, los pasos de reproducción, el impacto y el contacto del investigador; asignar responsable y seguimiento.
Verificación: reproducir en un entorno aislado; evaluar el alcance del impacto, la explotabilidad y los componentes afectados (frontend, backend, edge y almacenamiento).
Corrección: implementar el parche, añadir casos de prueba y de regresión y, si es necesario, añadir reglas de protección (WAF, limitación de frecuencia o endurecimiento de políticas).
Publicación: lanzamiento canary y monitorización de las métricas clave; lanzamiento completo tras confirmar que no hay regresiones ni nuevos riesgos.
Comunicación: explicar públicamente el impacto, el contenido de la corrección y las acciones que deban tomar los usuarios (si las hay), sin ampliar la superficie de ataque.

Para vulnerabilidades críticas o eventos de gran impacto en los usuarios, DEBERÍA publicarse información actualizada del evento o un análisis posterior a través de /status, en línea con el proceso de respuesta a incidentes del capítulo 10.

11.4 Vulnerabilidades que afectan a los límites del conocimiento cero

El núcleo del compromiso de conocimiento cero es que el servidor no pueda acceder a la CEK y que el entorno de descarga y descifrado esté lo más aislado posible, sin scripts de terceros. Por ello, las siguientes categorías DEBEN tratarse como máxima prioridad:

XSS / inyección: capacidad de ejecutar scripts arbitrarios en las páginas de descarga y descifrado, leyendo fragmentos o material de claves en memoria.
Inyección en la cadena de suministro: envenenamiento de dependencias, sustitución de artefactos de compilación o inyección en CDN/edge que lleve a la manipulación de scripts.
Filtración en registros y monitorización: fragmentos de URL, CEK, tokens o texto plano registrados accidentalmente y accesibles.
Política incorrecta de carga de recursos: páginas de descarga y descifrado que importan scripts de terceros, o relajación de la CSP que amplía la superficie de ejecución.

El tratamiento debe incluir: contención inmediata (retirar el código de riesgo, endurecer la política, bloquear el vector), publicación rápida de la corrección, análisis retrospectivo del impacto y una declaración clara en el comunicado sobre «si el material de claves o el texto plano pudieron quedar expuestos».

11.5 Actualizaciones de seguridad y verificación de regresiones

DEBE: establecer casos de regresión para los cambios relacionados con la seguridad (autenticación, control de acceso, CSP, filtrado de registros, flujos de cifrado).
DEBERÍA: realizar comprobaciones automatizadas en las páginas críticas (descarga y descifrado) para asegurar que no hay scripts de terceros y que las políticas de cabeceras coinciden con lo esperado.
DEBERÍA: volver a probar los elementos verificables externamente (p. ej., análisis de TLS y de cabeceras de seguridad) tras publicar la corrección.
DEBERÍA: documentar claramente los cambios de compatibilidad introducidos por las correcciones (p. ej., enlaces antiguos o manifiestos antiguos).

En coherencia con el capítulo 12: los análisis de terceros verifican algunas bases de referencia web, pero no pueden demostrar directamente los detalles completos de la implementación de conocimiento cero y E2EE; por ello, la verificación de regresiones debe cubrir tanto la implementación del protocolo como las bases de referencia visibles.

11.6 Versionado de protocolos y criptografía (cryptoVersion)

El cifrado y la implementación del protocolo de FileBolt DEBEN admitir versionado para facilitar las actualizaciones de algoritmos, corregir defectos de implementación e introducir un aislamiento más sólido. Se recomienda usar campos explícitos (p. ej., cryptoVersion) vinculados en el manifiesto o los metadatos.

Versión explícita: cada transferencia o manifiesto DEBE declarar su cryptoVersion para determinar los algoritmos, los parámetros y las reglas de codificación.
Sin inferencia implícita: el cliente DEBE decidir la lógica de análisis y descifrado a partir de campos explícitos del manifiesto, sin conjeturas ni heurísticas de respaldo.
Fallar en cerrado: DEBE fallar en cerrado ante versiones desconocidas o parámetros incoherentes, sin degradarse nunca a modos inseguros.

11.7 Compatibilidad, migración y retirada

11.7.1 Compatibilidad con versiones anteriores

DEBERÍA: admitir la lectura de versiones antiguas de transferencias durante los periodos de transición para minimizar el impacto en los enlaces históricos de los usuarios.
DEBE: declarar públicamente los límites de seguridad, las limitaciones y los planes de retirada de las versiones antiguas.

11.7.2 Migración (manteniendo el conocimiento cero)

DEBERÍA: ofrecer a los usuarios rutas de «volver a subir / volver a cifrar» si hace falta migrar de una versión antigua a una nueva.
DEBE: mantener el conocimiento cero durante la migración: el nuevo cifrado se realiza en el cliente y el servidor no puede acceder a la CEK ni al texto plano.

11.7.3 Retirada y fin de vida (EOL)

DEBE: ofrecer un calendario claro de fin de vida para las versiones que dejen de considerarse seguras.
DEBERÍA: avisar a los usuarios en la interfaz y en la documentación para que vuelvan a subir los archivos, y ofrecer ventanas de migración suficientes.
DEBE: tras el fin de vida, los clientes que encuentren versiones retiradas deberían avisar claramente y no deben intentar descifrar.

11.8 ID de afirmaciones relacionados (reservado)

Este capítulo trata sobre «canales de divulgación de vulnerabilidades, flujos de trabajo, versionado y retirada». Los ID de afirmaciones correspondientes se añadirán al Apéndice: índice de ID de afirmaciones como única fuente de referencia.