Inyección directa en API de KYC: cómo un video sintético salta la cámara

La mayoría de los flujos de verificación de identidad se diseñaron sobre una premisa cómoda: la imagen que llega al servicio proviene de una cámara física que el usuario controla en ese momento. Esa premisa sostiene buena parte de las comprobaciones de liveness, los retos por movimiento y el análisis de textura en el cliente. Cuando el atacante deja de usar la cámara y empieza a enviar fotogramas generados directamente al endpoint, la premisa se rompe y con ella toda la cadena de confianza que dependía del dispositivo.

El recorrido típico de una petición de verificación pasa por varias manos antes de llegar al backend: la aplicación móvil o web captura el stream, lo comprime, lo envía por HTTPS y el servicio lo recibe como un blob sin más contexto que el que el propio cliente declara. Ahí está el punto débil. Si el atacante instrumenta la app, intercepta la llamada o reemplaza el SDK por una implementación propia, puede inyectar un video sintético en el mismo sitio donde iría el stream legítimo. El servidor no tiene forma trivial de distinguir un fotograma capturado por un sensor de uno generado por un modelo, porque ambos llegan como bytes idénticos en el mismo formato.

Las señales que un backend puede observar cuando el origen real no es una cámara son sutiles y requieren mirar más allá del contenido visible. La coherencia temporal entre fotogramas, el patrón de ruido del sensor, la respuesta a estímulos enviados en tiempo real y los metadatos del contenedor aportan pistas que, combinadas, elevan la confianza de la decisión. Ninguna por separado basta: un video sintético bien construido puede imitar el ruido, pero rara vez reproduce la irregularidad natural de un sensor físico bajo condiciones variables de luz y red.

El problema de fondo es que las defensas centradas solo en el cliente no cubren este escenario. Un SDK ofuscado, un reto por movimiento o una validación de integridad del dispositivo elevan el coste del ataque, pero no lo eliminan. Si el atacante controla el entorno de ejecución, controla también lo que el cliente reporta. La barrera útil aparece cuando el servidor asume que el stream puede ser hostil y aplica análisis de procedencia, límites de tasa por identidad y validación de sesión antes de confiar en cualquier fotograma.

En la práctica, esto obliga a repensar dónde se coloca la verificación. No se trata de añadir una capa más al cliente, sino de mover parte del juicio al backend, donde el atacante no puede reescribir el resultado. Es un cambio de arquitectura más que de producto, y afecta a cómo se instrumentan las métricas, cómo se gestionan los falsos positivos y cuánta fricción se acepta para el usuario legítimo. La inyección directa no es un fallo de un SDK concreto: es una consecuencia de confiar en el origen del dato sin verificarlo.