Cómo un cliente de API en el navegador esquiva CORS sin abrir un proxy a SSRF
Tool Reign corre entero en el navegador y resuelve el muro de CORS con un modo directo y otro por proxy opcional. El autor detalla las defensas contra SSRF y el precio en privacidad.
Un desarrollador ha contado cómo está montado Tool Reign, un cliente de API que se ejecuta entero en el navegador, y en concreto cómo resolvió CORS sin acabar operando un proxy abierto a cualquiera. La herramienta no es de código abierto y en la entrada no hay una línea de código: lo que se puede leer son las decisiones de diseño.
El problema de fondo es conocido. Una página puede lanzar una petición a cualquier URL, pero solo leerá la respuesta si el servidor la autoriza. Eso es CORS, y muchas API no lo permiten. A eso se suman los límites del navegador: hay cabeceras que no se pueden fijar desde una página (Host, Origin, Cookie y alguna más), Set-Cookie no se puede leer, solo se ven las cabeceras de respuesta que el servidor decide exponer y no hay tiempos de DNS ni de TLS.
Directo o por proxy
La herramienta tiene dos modos. En el directo, la petición sale del navegador hacia la API sin pasar por ningún servidor intermedio, y funciona con cualquiera que permita CORS. En el proxy, opcional, el recorrido es navegador, servidor de Tool Reign, API: enseña cabeceras, cookies y tiempos que el navegador esconde y sirve para API que bloquean peticiones desde el navegador. El directo es el modo por defecto, y si una petición falla por CORS la aplicación ofrece reintentarla por el proxy, avisando antes de lo que ese proxy va a ver. Localhost y las redes privadas se quedan en directo a propósito.
El proxy es la parte peligrosa, y el autor lo dice sin adornos: un endpoint que va a buscar cualquier URL que le des es el manual de SSRF y atrae abuso. Resuelve el nombre de host y rechaza todo lo privado o reservado (loopback, rangos privados, link-local, incluida la dirección de metadatos de la nube, CGNAT, multicast y sus equivalentes en IPv6, también las IPv4 mapeadas); se conecta a la dirección ya validada en vez de volver a resolver, para que el DNS rebinding no cuele una IP privada; no sigue redirecciones automáticamente, comprueba cada salto y no arrastra Authorization ni Cookie a otro origen; limita petición (5 MB), respuesta (10 MB) y tiempo (30 segundos); acepta llamadas solo desde el propio origen y con límite de peticiones; y no guarda nada. Los registros se quedan en un identificador de petición, una clase de estado, un código de error y una duración.
El precio en privacidad
Lo más sensible que se teclea en un cliente de API son los tokens y las claves, y un proxy los ve. Por eso el modo es opcional, la primera vez aparece un aviso de consentimiento y el propio autor recomienda no usarlo con credenciales de producción. Quien no quiera confiar en un intermediario tiene el modo directo, que no toca su servidor.
Del despliegue saca tres averías. El zip lo generó en Windows con Compress-Archive, que escribió rutas con barras invertidas: el host Linux vio ficheros llamados literalmente src\server.js y murió con un cannot find module. El chequeo de salud de la plataforma lo rechazaba el filtro de origen, así que la aplicación seguía marcada como no sana; esas rutas hay que exceptuarlas. Y en algún punto el registro A de su dominio acabó en un "Parked" del registrador, sin que llegara a identificar qué paso lo provocó.
La herramienta trae colecciones, entornos con variables, historial de peticiones, parámetros, cabeceras, cuerpo y autenticación, y del lado de la respuesta cuerpo, cabeceras, cookies y tiempos, además de fragmentos de código e importación, copia de seguridad y restauración. Se puede probar en el cliente de API.
Lo aprovechable no es el producto, sino la lista de comprobaciones: si algún día toca montar un proxy para saltar CORS, cada punto de esa lista es una decisión que alguien va a auditar.
