Logo

Informe técnico sobre seguridad y privacidad (descripción general)Capítulo 11

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

FileBolt fomenta la divulgación responsable y genera confianza a través de mecanismos de comunicación y remediación predecibles. Al mismo tiempo, las capacidades de seguridad deben poder evolucionar: incluidas políticas de seguridad web, mecanismos de autenticación del lado del servidor e implementaciones de protocolos/encriptación de extremo a extremo (por ejemplo, cryptoVersion actualizaciones). Este capítulo describe los canales de contacto público, los flujos de trabajo de procesamiento, los principios de lanzamiento y anuncio de remediación, y explica las estrategias de desaprobación y evolución de las versiones.

11.0 Resumen

  • MUST: Proporcionar canales públicos de envío de vulnerabilidades (por ejemplo, seguridad.txt y correo electrónico de soporte).
  • SHOULD: proporcione mecanismos de envío cifrados (por ejemplo, clave PGP) para el envío seguro de detalles.
  • SHOULD: Defina una respuesta clara y una cadencia de remediación (SLA/cronogramas objetivo) y comuníquese a través de la página de estado cuando sea necesario.
  • MUST: Trate las vulnerabilidades que potencialmente afecten los compromisos de conocimiento cero (XSS, inyección en la cadena de suministro, fuga de fragmentos de registros) como máxima prioridad.
  • MUST: Implementar evolución versionada (cryptoVersion) y definir estrategias de compatibilidad, migración y desaprobación.

11.1 Canales y contacto para el envío de vulnerabilidades

11.1.1 Puntos de entrada públicos

  • MUST: Proporcionar canales de envío de vulnerabilidades, vencimiento y enlaces de políticas en /.well-known/security.txt.
  • MUST: proporcione un correo electrónico de contacto de seguridad accesible (p. ej., soporte@filebolt.net o dedicado seguridad@filebolt.net).
  • SHOULD: Proporcionar instrucciones breves y pautas de envío sobre el Seguridad y privacidad page.

11.1.2 Envío cifrado y manejo de información confidencial

  • SHOULD: Proporcione una clave pública PGP (o equivalente) para que los investigadores envíen detalles de reproducción de forma segura.
  • MUST: Aplique visibilidad con privilegios mínimos para los detalles de la vulnerabilidad internamente, revelándolos solo al personal requerido para la reparación.
  • MUST: Prohibir a los investigadores incluir texto plano del usuario, CEK, fragmentos de URL o material clave derivable en los informes; si se incluye inadvertidamente, el equipo DEBE tratarlo como un incidente sensible y limitar su difusión.

11.2 Plazos de respuesta y principios de comunicación

Los cronogramas dependen de la escala y la complejidad del equipo, pero el proyecto DEBE proporcionar una cadencia de objetivos predecible y comunicar rápidamente si no se cumplen los objetivos. Objetivos recomendados (ajustables según la realidad y publicados en /security o security.txt):

  • Primera respuesta: Por ejemplo, acusar recibo y asignar ID de seguimiento dentro de las 48 horas.
  • Evaluación inicial: Por ejemplo, completar la clasificación de gravedad y la evaluación del alcance del impacto en un plazo de 7 días.
  • Reparar lanzamiento: Progreso basado en la gravedad; P0/P1 priorizado para una rápida reparación y liberación.

SHOULD: Mantenga la comunicación necesaria durante el procesamiento (por ejemplo, reproducido/no reproducido, necesita más información, ventana de reparación estimada) y evite revelar públicamente detalles explotables.

11.3 Proceso de divulgación

  1. Receipt: información del informe de registro, pasos de reproducción, impacto y contacto del investigador; asignar propietario y seguimiento.
  2. Verification: Se reproducen en ambiente aislado; evaluar el alcance del impacto, la explotabilidad y los componentes afectados (Frontend/Backend/Edge/Storage).
  3. Remediation: Implementar parche, agregar casos de prueba/regresión, agregar reglas de protección si es necesario (WAF/Límite de tasa/Ajuste de políticas).
  4. Release: Canary publica y monitorea métricas clave; lanzamiento completo después de confirmar que no hay regresión ni nuevos riesgos.
  5. Announcement: Explique públicamente el impacto, corrija el contenido y las acciones requeridas por el usuario (si corresponde) sin expandir la superficie de ataque.

Para vulnerabilidades críticas o eventos de alto impacto para el usuario, SHOULD publicar actualizaciones de eventos o autopsias a través de /status alineado con el proceso de IR del Capítulo 10.

11.4 Vulnerabilidades que afectan los límites del conocimiento cero

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

  • XSS / Inyección: Capacidad de ejecutar scripts arbitrarios en páginas de descarga/descifrado, fragmentos de lectura o material de clave de memoria.
  • Inyección en la cadena de suministro: Envenenamiento de dependencias, reemplazo de artefactos de compilación, inyección de CDN/Edge que conduce a la manipulación de scripts.
  • Registro/monitoreo de fugas: fragmento de URL, CEK, token o texto sin formato registrado y accesible accidentalmente.
  • Política de carga de recursos incorrecta: Descarga/descifrado de páginas que importan scripts de terceros, relajación de CSP que amplía la superficie de ejecución.

La eliminación debe incluir: contención inmediata (código de riesgo fuera de línea/política más estricta/vector de prohibición), liberación rápida de soluciones, análisis de impacto retrospectivo, y una declaración clara en el anuncio sobre "si material clave o texto sin formato estuvo potencialmente expuesto".

11.5 Actualizaciones de seguridad y verificación de regresión

  • MUST: Establecer casos de regresión para cambios relacionados con la seguridad (Auth, Control de acceso, CSP, Filtrado de registros, Flujos de cifrado).
  • SHOULD: realice comprobaciones automatizadas en páginas críticas (descarga/descifrado) para garantizar que ningún script de terceros ni políticas de encabezado coincidan con las expectativas.
  • SHOULD: Realice una nueva prueba externa de elementos verificables (por ejemplo, escaneos de encabezado de seguridad/TLS) después de la publicación de la corrección.
  • SHOULD: Documente claramente los cambios de compatibilidad introducidos por las correcciones (por ejemplo, enlaces antiguos/manifiesto antiguo) en la documentación.

De acuerdo con el Capítulo 12: Los análisis de terceros verifican algunas líneas de base web, pero no pueden probar directamente los detalles completos de la implementación de Conocimiento Cero/E2EE; por lo tanto, la verificación de la regresión debe cubrir tanto la implementación del protocolo como las líneas de base visibles.

11.6 Versiones de protocolo y criptografía (cryptoVersion)

La implementación del protocolo y el cifrado de FileBolt DEBEN admitir versiones para facilitar las actualizaciones de algoritmos, corregir defectos de implementación e introducir un aislamiento más sólido. Se recomienda utilizar campos explícitos (p. ej., cryptoVersion) vinculado en manifiesto/metadatos.

  • Versión explícita: Cada transferencia/manifiesto DEBE declarar su cryptoVersion para determinar algoritmos, parámetros y reglas de codificación.
  • Sin inferencia implícita: El cliente DEBE decidir la lógica de análisis y descifrado basándose en campos de manifiesto explícitos, sin adivinanzas ni heurísticas alternativas.
  • Fallo cerrado: DEBE fallar al cerrarse al encontrar versiones desconocidas o parámetros inconsistentes, nunca degradar a modos inseguros.

11.7 Compatibilidad, migración y desaprobación

11.7.1 Compatibilidad con versiones anteriores

  • SHOULD: Admite la lectura de versiones de transferencia antiguas durante los períodos de transición para minimizar el impacto en los enlaces históricos de los usuarios.
  • MUST: indique públicamente los límites de seguridad, las limitaciones y los planes de desuso para versiones anteriores.

11.7.2 Migración (manteniendo conocimiento cero)

  • SHOULD: Proporcione rutas del lado del usuario "Volver a cargar/Volver a cifrar" si es necesaria la migración de la versión anterior a la nueva.
  • MUST: Mantenga el conocimiento cero durante la migración: el nuevo cifrado se produce en el cliente, el servidor no puede acceder a CEK ni al texto sin formato.

11.7.3 Desuso y EOL

  • MUST: Proporcionar un cronograma claro de fin de vida útil para las versiones que ya no se consideran seguras.
  • SHOULD: Solicite a los usuarios que vuelvan a cargar en UI/Docs y proporcione suficientes ventanas de migración.
  • MUST: Después del EOL, los clientes que encuentren versiones obsoletas deben avisar claramente y no deben intentar descifrar.

11.8 ID de reclamaciones relacionadas (reservadas)

Este capítulo cubre "Canales de divulgación de vulnerabilidades, flujos de trabajo, versiones y obsolescencia". Los ID de reclamo correspondientes se agregarán a la Apéndice: Lista maestra de ID de reclamaciones como única fuente autorizada.