Cazando Web Apis

Por motivos de arquitectura, performance o presentación de una aplicación web, algunos desarrolladores definen que las búsquedas o procesamiento de datos dentro de una página las realizara una api web, externalizando el procesamiento de los datos y dejando solo la presentación en la capa web, generalmente estas api retornan resultados en xml o json y es trabajo de la capa de presentación tabularlas y mostrarlas,  esto a veces permite que la pagina no se tenga que recargar cada vez que muestra el resultado de una búsqueda u otra operación en línea. En algunos casos las consultas a la api se realizan desde el cliente (via ajax o web sockets) y no desde el servidor, entonces es necesario que la api web sea pública para ser consumida desde cualquier lugar donde esté ubicado el cliente.

Generalmente es fácil reconocer que se está haciendo uso de una api web de este tipo, por lo que mencionamos antes, que la página no se refresca completa, sino solo algunos campos.

Como podemos ver en el siguiente ejemplo, al ingresar un Rut válido y presionar el botón Buscar la página no se recarga, pero si actualiza algunos campos para mostrar el resultado de la búsqueda, Bingo!, al parecer estamos en presencia de una api web en acción.

búsqueda de un rut.
Resultado de la búsqueda sin recargar la página.

¿Cómo podemos verificar esto y saber qué api se está consumiendo desde la aplicación web? Para esto haremos uso de una maravillosa herramienta, el F12, su nombre real es Firefox Developer Tools, pero le decimos F12 de cariño, ya que con esa tecla se activa y desactiva la herramienta desde Firefox.

Entonces vamos a la página con Firefox y presionamos F12, y recargamos la página presionando el botón “Recargue” que aparece en la ventana nueva

Recargar la pagina para ser analizada por F12.

Luego que la página se recargue vamos a la pestaña red, donde podremos ver el tráfico que fluye entre nuestro navegador y los servidores.

Y realizamos nuevamente la búsqueda

Aquí a la izquierda nos aparece el tráfico realizado. Qué se consumió y con qué parámetros.

Tráfico web.

Podemos reconocer el Rut que ingresamos en la búsqueda, así que por ahí seguimos, pinchamos la línea en cuestión y se nos habilita a la derecha una nueva ventana que nos muestra más detalle de la solicitud GET.

Por ejemplo podemos ver los parámetros que se enviaron.

O las cookies que se utilizan, en este caso no hay.

¿Que datos responde la api?

Y los que nos interesa, ¿que url se esta consumiendo?

Copiamos la url, le cambiamos el Rut, la consumimos en el navegador y Voila!.

Ahora podemos usar esta api web, ya que es publica y abierta 😉

¿Como podemos mitigar esta fuga de información? la solución no es tan complicada, una forma es: asegurar que la búsqueda de los datos esté después de autenticarse de alguna forma, por ejemplo un login. Puede ser que la búsqueda de información este después del Login en el flujo del sitio.

Al autenticarnos podemos obtener un token de sesión y así validamos que la api realice la búsqueda solo cuando recibe un token de sesión válido ademas de los parámetros de búsqueda, nos aseguramos que quien reciba el resultado de la búsqueda sea un usuario autorizado. Un estándar muy conocido de este patron de seguridad es el JSON Web Token y para ver las distintas implementaciones en varios lenguajes de programación pueden entrar a jwt.io.

Ya tendremos oportunidad de ahondar mas sobre esta técnica para asegurar nuestras apis.