Análisis estático: secretos, claves y rutas dentro del paquete

Al descompilar Colibrí aparece, entre las cadenas, una clave de API de un servicio de terceros escrita directamente en el código. Estaba ahí para que la aplicación pudiera llamar a ese servicio sin pedirle nada al usuario. El problema es que esa clave viaja en cada copia instalada: cualquiera que abra el paquete la lee, tal como acabas de hacer. La gravedad depende de qué permite esa clave —si factura contra la cuenta de la empresa, es grave—, pero el patrón es el mismo.

La mitigación no es ofuscar la clave para que «cueste encontrarla». Ofuscar retrasa, no cierra: el secreto sigue en el cliente. La corrección es sacar el secreto del cliente —que la llamada al tercero la haga el servidor de Colibrí, y la aplicación hable solo con su propio servidor—.

El barrido estático marca muchas cadenas, y no todas son un secreto. Una clave pública, un identificador de la aplicación o el nombre de un servidor no son credenciales: son datos que de todos modos viajan o que no dan acceso a nada por sí solos. Confundir un identificador con una credencial llena el informe de ruido y quema la confianza de quien tiene que arreglarlo. El criterio es preguntar qué se puede hacer con el valor: si abre algo, es secreto; si solo nombra algo, no.

En Colibrí el barrido señala tres cadenas: una clave que factura contra un servicio de pago, una clave pública de verificación de firmas, y el identificador interno de la aplicación. Solo la primera da acceso a algo.

Entre las cadenas aparecen las direcciones de la API que la aplicación usa, incluidas algunas rutas de administración que la interfaz nunca muestra. Eso es información útil para el análisis: dice dónde mirar después, en el módulo de la API. Pero conocer una ruta no es en sí una vulnerabilidad —que exista /admin/exportar no significa que cualquiera pueda usarla—. El hallazgo real aparecerá cuando se compruebe si el servidor protege esa ruta o confía en que la aplicación no la llame.

En Colibrí encuentras la ruta /interno/usuarios que la app usa solo para su panel de soporte. Anotas que existe y por dónde seguir; el veredicto se decide contra el servidor, no aquí.

Cerrar este tipo de hallazgo pieza por pieza —quitar esta clave, mover esta otra— trata el síntoma. La causa raíz es un modelo donde el cliente guarda algo que le da acceso directo a un recurso que factura o que expone datos. El arreglo duradero es una regla de arquitectura: el cliente no custodia secretos de servidor; si hace falta hablar con un tercero de pago o con un recurso sensible, ese paso ocurre en el servidor, que sí puede guardar un secreto y decidir quién lo usa. Escribir eso en el informe evita que la clave siguiente reaparezca en la próxima versión.

En el informe de Colibrí no anotas «borrar la clave X»: anotas «ningún secreto de servidor vive en el cliente; las llamadas a servicios de pago pasan por el backend, que autentica a cada usuario».

Abre el laboratorio y recorre las cadenas que marcó el barrido estático de Colibrí. De las tres, quédate solo con la que de verdad da acceso a algo que factura, descartando la clave pública y el identificador. Junto a ese hallazgo hay un código de la sala. Escríbelo tal cual.