Caso final — Tejón Salud

Tienes el paquete de Tejón, su API y el emulador, y ninguna indicación. La tentación es saltar a lo llamativo —enganchar funciones para «romper» algo— pero eso mide resistencia del cliente, no dónde están los datos. El orden que transfiere el método es otro: abrir el paquete y leer lo que trae (rutas de la API, secretos, manifiesto), mirar qué guarda en el dispositivo, y poner el proxy para ver el diálogo con la API, que es donde viven los datos de los pacientes. El análisis del cliente sirve para encontrar la superficie; el veredicto se decide contra el servidor.

Empiezas por el análisis estático y el tráfico, no por enganchar. Con eso construyes el mapa de la API antes de probar nada contra ella.

Mapeada la API de Tejón, pruebas la ruta que devuelve los resultados médicos: la app los pide por el identificador del paciente. Con tu sesión de paciente cambias ese identificador por otro y el servidor responde con los resultados de otra persona —análisis, diagnósticos, datos de salud—. Es un control de acceso roto sobre datos sensibles, y si los identificadores son correlativos, el alcance es toda la base de pacientes. Este es el hallazgo central del caso, y no estaba en ninguna parte del cliente: estaba en que el servidor no comprueba de quién es lo que pide.

Lo documentas con una muestra mínima que prueba el alcance, sin descargar datos de pacientes de más, y con la remediación en el servidor: comprobar en cada petición que el resultado pertenece a la sesión que lo pide.

Tejón fija el certificado y, cuando montas el proxy, la aplicación deja de conectar hasta que saltas la fijación en tu emulador. Es fácil escribir «fijación vencida» como titular del informe, pero eso mediría una defensa del canal en tu propio dispositivo, no un fallo que exponga a los pacientes. La fijación cumplía su papel frente a intermediarios en la red; el problema de Tejón no es el canal —que va cifrado— sino lo que el servidor acepta una vez que la petición llega. Poner la fijación en el titular desviaría la atención del control de acceso roto, que es lo que hay que arreglar.

En el informe la fijación se menciona como lo que es —una defensa de canal que el analista salta en su equipo para poder mirar—, no como hallazgo. El titular es el acceso a datos ajenos en la API.

En el análisis estático viste que Tejón tiene una función de anulación de citas que la app solo muestra al personal de recepción, comprobando el rol en el cliente. Lo confirmas contra la API: llamas a la ruta de anulación con tu sesión de paciente, y el servidor anula la cita. El control de recepción vivía únicamente en la interfaz; el servidor no comprueba el rol. Un paciente podría anular citas ajenas hablando directo con la API. El hallazgo no es que la pantalla se pudiera abrir, es que la acción se ejecuta sin autorización en el servidor.

Se cierra en el servidor: la ruta de anulación verifica el rol derivado de la sesión y que la cita corresponda a quien la anula, denegando por defecto. Ocultar el botón en la app no habría cambiado nada.

Cierras el caso de Tejón con el informe para la clínica. El hallazgo que encabeza es el acceso a resultados médicos ajenos, por su impacto sobre datos de salud; le sigue la anulación de citas sin autorización; y se listan los de cliente —lo que hubiera de secreto o de dato local— con su peso real. Cada uno lleva su mitigación, y las que cierran el impacto van en el servidor: propiedad del recurso, rol desde la sesión, denegar por defecto. Las medidas de cliente —proteger el almacenamiento, no embeber secretos— se anotan donde el cliente es el lugar correcto; la ofuscación y el bloqueo por root, si aparecen, como fricción, no como cierre. El mensaje de la ruta entera queda en una línea del informe: arreglar la aplicación sin arreglar la API no cierra nada.

Si llegaste hasta aquí —mapeando la API antes de enganchar, probando el acceso a lo ajeno con muestra mínima, sin poner la fijación en el titular, y mandando las remediaciones de impacto al servidor—, el método de la ruta ya es tuyo.

El caso no se cierra con una impresión, se cierra con la prueba del hallazgo que encabeza el informe. Vuelve al laboratorio de Tejón, repite contra la API la petición de un resultado médico con un identificador de paciente que no es el tuyo, y comprueba que el servidor devuelve los datos de salud de otra persona. En la revisión de esa respuesta —el hallazgo central de toda la ruta— hay un código de la sala. Escríbelo tal cual.