Falsos hallazgos y límites de la captura: qué evidencia basta

Una captura hecha en un emulador con un proxy de laboratorio tiene límites que el informe debe nombrar. Solo ve el recorrido que se hizo con la cuenta que se usó; no ve lo que el servidor hace con los datos una vez recibidos; el emulador no se comporta igual que todos los teléfonos; y el propio proxy altera el entorno, porque hay que instalarle una autoridad de certificación antes de que las conexiones cifradas funcionen.

Eso no invalida la captura: delimita lo que puede afirmar. Un buen informe separa lo observado, lo inferido y lo que queda sin comprobar, y no mezcla las tres cosas en una misma frase.

Abre red.log y uids.txt. El emulador comparte red con otras aplicaciones, y el registro recoge el tráfico de todas. La columna del uid dice de quién es cada línea, y uids.txt traduce el uid a paquete. Una petición hacia un servicio de sincronización de hora que figura bajo otro uid no la hizo Barranquero, aunque aparezca entre sus líneas y a la misma hora.

Atribuir una línea a la aplicación equivocada es el error más barato de cometer y el más caro de retirar: el informe llega a la empresa con una acusación a su aplicación por lo que hizo otra.

Lee notas-de-captura.txt y el guion. Las primeras conexiones cifradas de la sesión fallan con un error de autoridad no reconocida. Parece un problema de validación del certificado de la aplicación, pero las notas explican que en ese momento la autoridad del proxy aún no estaba instalada en el emulador: el fallo lo produjo la herramienta de captura, y desaparece en cuanto se instala y se reabre la aplicación.

Un artefacto de la captura se reconoce porque su causa está en el entorno y no en la aplicación: la hora lo delata. Se anota en el informe como limitación de la captura, no como hallazgo.

De los cinco candidatos, uno es una petición de otra aplicación, otro un artefacto de la captura, otro el funcionamiento normal de la autenticación por cabecera, y otro un rechazo seguido de la renovación de la sesión y el reintento correcto, que es lo que hace cualquier aplicación cuando caduca su credencial. Queda uno, que la traza sostiene con sus propias líneas: una consulta que el servidor contesta sin que la petición lleve ninguna credencial.

Para separarlo no hace falta saber más de la aplicación: hace falta leer la columna de credenciales y la de estado de cada línea, y cruzarlas con el guion.

Para sostener el hallazgo que quedó, la traza ya trae mucho: dos líneas con su hora, que coinciden con dos acciones del guion, con la misma respuesta y el mismo tamaño, y la nota de que el registro guarda todas las cabeceras. Eso es evidencia suficiente para registrarlo como hallazgo fundado. Lo que la traza no puede dar es la confirmación del lado del servidor: un solo recorrido desde un emulador no prueba que la respuesta no dependa de otra cosa, como una cookie que el registro no resume.

Por eso se redacta con lo observado, se marca la confirmación pendiente y se repite la petición contra la API de laboratorio, con autorización, antes de cerrar el hallazgo.