Esquemas de URL, enlaces universales y seguridad de transporte

Un esquema de URL propio, como el que una app declara en su archivo de propiedades, se reserva sin comprobar a quién pertenece: Apple no garantiza que un esquema sea único, y varias apps pueden declarar el mismo. Quien manda un enlace con ese esquema no sabe qué app lo recibe, y la app que lo recibe no sabe quién lo mandó. Por eso lo que llega por un esquema es una entrada no fiable, como cualquier otra.

Un enlace universal es una dirección web normal. Para que el sistema la entregue a la app, el dominio tiene que publicar un archivo de asociación en una ruta conocida, con el identificador del equipo y de la app, y la app tiene que declarar el dominio en sus entitlements. La confirmación viene de quien controla el dominio, no de una reserva abierta.

Como lo que llega por un esquema es una entrada no fiable, las rutas que hacen algo con consecuencias necesitan sus propias barreras: sesión iniciada, validación de los parámetros y una confirmación del usuario antes de ejecutar. Una ruta que registra un pago, cambia un dato o envía algo con un solo toque en un enlace es un riesgo porque cualquier página, mensaje o app puede construir ese enlace.

El inventario del equipo de desarrollo lista cada ruta con dos columnas: si exige sesión y si pide confirmación. Lee las tres rutas de Quetzal y localiza el esquema cuya ruta ejecuta una operación con dinero sin pedir confirmación.

Para que un enlace universal funcione, cada dominio declarado en los entitlements de la app tiene que publicar su archivo de asociación en la ruta conocida de ese dominio, y responder con un 200 y contenido JSON. Un dominio declarado cuyo archivo devuelve un error no funciona como enlace universal: el sistema no confirma la asociación y los enlaces de ese dominio se abren en el navegador, no en la app.

Es un fallo de configuración con una consecuencia de seguridad indirecta: el equipo cree que esos enlaces están protegidos por la verificación de dominio y no lo están. Compara los dominios declarados con la respuesta que da cada uno.

La seguridad de transporte de aplicaciones exige por defecto HTTPS con TLS 1.2 o superior, cifrado fuerte y confidencialidad hacia adelante. La app puede relajar eso con excepciones por dominio, y las hay de varios tipos: permitir HTTP sin cifrar, rebajar la versión mínima de TLS o desactivarla para toda la app. La más grave es la que permite el canal sin cifrar, porque lo que viaja por él se lee y se modifica en el camino.

El archivo de configuración de Quetzal tiene la desactivación global en falso y una lista de excepciones por dominio. Lee las excepciones y localiza el dominio al que se le permite el canal sin cifrar.

El resumen de las conexiones de prueba muestra que la app habla con el dominio de la excepción por HTTP y que el número de póliza va en la dirección, así que cualquiera con acceso a la red entre el teléfono y el servidor lo lee. La excepción no es el origen del problema: es el síntoma de un servidor que no ofrece HTTPS.

Cerrar el hallazgo es arreglar el servidor, para que ofrezca HTTPS, y después retirar la excepción para que la app vuelva a exigirlo. Dejar la excepción y pedir al equipo «más cuidado» no reduce el riesgo, y desactivar la protección para toda la app lo agranda.