QMission
React Flight Protocol
Aprendizaje interactivo • Seguridad, Ciberdefensa y RSC

React Flight Protocol — Visión QMission

React Flight es el protocolo que orquesta la comunicación entre el servidor y el cliente en React Server Components (RSC) y Server Actions. Serializa datos, referencias y resultados de ejecución en el servidor para que el cliente reconstruya la UI eficientemente. Desde ciberseguridad, nos interesa su superficie de ataque: el flujo de serialización/deserialización, las referencias a “chunks” y las rutas de propiedades que, si no se validan correctamente, abren la puerta a acceso no autorizado y potencial RCE.

Enfoque: NIST CSF 2.0 • ID.AM, PR.DS, DE.CM, RS.MI
NICE-NIST • Secure Software, Incident Response
MITRE ATT&CK • TA0001, TA0006, TA0007, TA0009

Arquitectura de Flujo

Del cliente al servidor y de vuelta, con Flight en medio:

  1. Invocación de Server Action/Componente en cliente.
  2. Serialización (Flight) de datos, referencias y chunks.
  3. Ejecución en servidor y preparación de respuesta.
  4. Deserialización en cliente y reconciliación React.
Sello QMission: validación estricta de entradas antes de deserializar y control de rutas de propiedad.

Beneficios operativos

  • Menor JS en cliente, mejor TTI.
  • Trabajo intenso se resuelve en servidor.
  • Transporte incremental vía “chunks”.
Eficiencia estimada en escenarios típicos RSC

Riesgos clave

  • Deserialización sin validación robusta.
  • Rutas de propiedad profundas (constructor, prototype).
  • Exposición de módulos internos no exportados.

Principio: “Never trust flight payloads”.

Formato de Serialización Flight

Flight utiliza marcadores para representar tipos y referencias durante el transporte. Entenderlos es crítico para evaluar riesgo y diseñar controles defensivos.

Marcadores frecuentes

  • $@: referencia a chunk serializado.
  • $B: referencia a Blob (binarios).
  • $ y caminos de propiedad: p. ej. $1:constructor:constructor
Ejemplo de ruta de propiedad
// Serializado (Flight)
$1:constructor:constructor

// Equivale a JS conceptual:
reference[1].constructor.constructor

Poderoso para acceder profundo, peligroso si no se restringe el espacio de propiedades.

Visualizador de Chunks

Observa cómo cambian las referencias entre escenarios.

Simulador: Serialización

Escribe un objeto JS y observa su “flight-like” JSON serializado con marcadores simplificados.

Simulador: Deserialización

Pega un payload “flight-like” y observa cómo se reconstruye. El motor incluye validaciones defensivas.

Política de validación (QMission)
  • Lista blanca de propiedades permitidas (deny-by-default).
  • Bloqueo de “constructor”, “prototype”, “__proto__”, “caller”, “callee”.
  • Prohibición de Function y eval-like.
  • Límites de profundidad y tamaño de payload.

Laboratorio guiado: Superficie de ataque

Este laboratorio didáctico ilustra cómo rutas de propiedad mal validadas podrían derivar en acceso a primitivas peligrosas. No ejecuta código real de ataque: es una simulación segura para concienciación.

  1. Selecciona el preset “Ruta sospechosa”.
  2. Serializa y revisa el marcador $path.
  3. Deserializa con la política QMission activada y observa el bloqueo.
Objetivo pedagógico: demostrar por qué la validación de propiedades es esencial antes de materializar referencias.

Indicadores de Riesgo

  • Presencia de “constructor:constructor”.
  • Caminos con prototype o __proto__.
  • Marcadores ambiguos sin namespace de módulo.

Mapea estos indicadores a DE.CM y PR.AC del NIST CSF.

Mitigaciones y Controles (CSF 2.0, NICE, ATT&CK)

Diseño seguro

  • Validación estricta de rutas: allow-list por módulo/espacio.
  • Deshabilitar o sandboxear acceso a propiedades dinámicas.
  • Firmar y versionar el payload (integridad, anti-downgrade).

Controles en ejecución

  • Límites de profundidad, tamaño y tasa (anti DoS de deserialización).
  • WAF con reglas para patrones “constructor:constructor”.
  • Observabilidad: logs estructurados de Flight, trazas y alertas.

Resiliencia y respuesta

  • Kill-switch de Server Actions y toggles por feature flag.
  • SBOM + SCA para detectar versiones vulnerables.
  • Playbooks RS.MI: contención, revocación de tokens, rotación de claves.

Autoevaluación QMission

Valida tu comprensión. Las respuestas aparecen al final.

  1. ¿Qué rol cumple el marcador $@ en Flight?
  2. ¿Por qué es peligroso $1:constructor:constructor si no se valida?
  3. Menciona dos controles para mitigar abuso de rutas de propiedad.
  4. ¿Qué capacidades de monitoreo implementarías para detectar intentos de explotación?
QMission • React Flight Protocol Interactivo • Hecho para formación técnica en Ciberseguridad y Ciberdefensa.