El último tipo de mala configuración que veremos será la cross-service. Los JWT se usan en sistemas centralizados. Sin embargo, puede que queramos restringir qué aplicaciones son accedidas con un JWT, especialmente cuando hay claims que deberían ser validadas por ciertas aplicaciones. Esto puede hacerse usando el claim audience. Sin embargo, si no está reforzado correctamente, puede darse un ataque cross-service relay para realizar una escalada de privilegios.
El Audience Claim
Los JWTs pueden tener un claim audience. En los casos donde un sólo sistema de autentificación sirve múltiples aplicaciones, el claim de audience puede indicar para qué aplicación está hecho un determinado JWT. Sin embargo, este refuerzo debe darse en la aplicación en sí misma, no en el servidor de autentificación. Si este claim no se verifica, como el JWT sigue siendo percibido como válido, puede tener consecuencias no intencionadas.
Un ejemplo de esto es si un usuario tiene privilegios de administrador o un rol más elevado en cierta aplicación, el JWT guardado para el usuario tiene un claim que indica "admin": true. Sin embargo, ese mimo usuario no es admin en otra aplicación servida por el mismo sistema de autentificación. Si el claim audience no se verifica en la segunda aplicación, el servidor tomará por error a dicho usuario como uno con privilegios elevados.
Ejemplo Práctico 7
Para este ejemplo, hay dos endpoints API llamados example7_appA y example7_appB. Puedes usar la misma petición GET que hiciste en el resto de ejemplos para recuperar la flag. Además, para la autentificación tienes que incluir "application": "appX" en la petición de login.
- Nos autentificamos en
example7usando el segmento'{ "username" : "user", "password" : "password7", "application" : "appA"}'.
- Usamos este token en peticiones admin y user que haremos a
example7_appAyexample7_appB.
Vemos que la app A lo aceptó pero no somos admin. Sin embargo, B ni siquiera lo aceptó porque la audiencees errónea. - Nos autentificamos en
example7usando el siguiente segmento ahora'{ "username" : "user", "password" : "password7", "application" : "appB"}'. Veremos que el claim audience es añadido y que ahora somos admin.
El Error de Despliegue
El problema clave es que el claim audiencia no ha sido verificado en appA. Esto puede ser porque la verificación del claim audience ha sido apagada o que el scope de la audiencia es demasiado amplio.
El Arreglo
El claim audience debería ser verificado cuando se decodifica el token. Esto puede hacerse como se muestra debajo.
payload = jwt.decode(token, self.secret, audience=["appA"], algorithms="HS256")