La autenticación de acceso básica descrita en el RFC 7617, se sirve de la cabecera Authorization de HTTP para enviar en cada petición las credenciales de acceso. Estas se envían en un formato de usuario:contraseña codificado en base64. Para los neófitos en seguridad, hay que destacar que establecer un mensaje en una codificación es muy distinto de cifrar su contenido, ya que en todo momento puede realizarse el proceso inverso para obtener las credenciales sin necesidad de ninguna clave.
|
Usuario |
WOCU |
|
Contraseña |
A3SEC |
|
Cabecera resultante |
Authorization: Basic V09DVTpBM1NFQw== |
Aunque el mecanismo esté disponible de forma nativa en muchos servidores web y tenga sus casos de uso, no todo son ventajas.
El principal inconveniente viene dado de la necesidad de enviar el usuario y contraseña en cada petición realizada al servidor web. Esto obliga a que la aplicación que lo envía deba conocer las credenciales del usuario por el que realiza la acción.
Otro inconveniente asociado al uso de APIs con esta autenticación, vendría por el cambio de credenciales del usuario, ya que estas deberían volver a guardarse en todos los lugares desde los que se realicen acciones en su nombre. En caso de que la actualización no se produjera, la aplicación web rechazaría el acceso a la misma pues las credenciales hasta que se actualizasen serían inválidas.
En la autenticación por token de sesión, conocida normalmente como autenticación por sesión, se genera un token asociado internamente a un usuario. Este token suele tener además una caducidad establecida.
Ejemplo:HKQzMXHbeSmDlrT1WaBi5vzxoG1JmDi5JWJvaVozENCS5Vz46HGauRewAV5ulH0EznS
|
token |
rAihWGJSzLGEwJqeiRsV |
|
usuario |
admin |
|
caducidad |
01/2020 |
Este token es enviado y recibido en cada petición HTTP. El servidor al recibirlo busca la existencia de un usuario asociado a este y procede a realizar acciones en su nombre de haberlo.
El token de sesión suele enviarse como una cookie para aprovechar la naturaleza de estas, dado que por defecto son enviadas en cada petición al mismo dominio por el navegador web en cuestión.
Otra ventaja de las cookies como almacenamiento de tokens de sesión, es que ante una vulnerabilidad del tipo XSS los tokens de sesión se protegen de ser capturados mediante el atributo httpOnly de las cookies. Esto se debe a que cuando se especifica el atributo HttpOnly en una cookie, esta deja de ser accesible mediante javascript.
La siguiente captura corresponde a un servidor de desarrollo de WOCU dónde se puede observar el uso del flag HttpOnly.
Una posible mejora sería forzar en aquellas instalaciones que dispongan de conexión HTTPS en producción (deberían ser todas), el flag secure que obliga a que la cookie solo pueda ser transmitida por HTTPs.
El uso de cookies de sesión puede dar lugar a ataques del tipo CSRF, pero si observamos los formularios de WOCU podemos ver que todos tienen, o deberían tener, protección contra CSRF, puesto que viene dado de forma inherente desde el set de tecnologías que utilizamos en su desarrollo.
Si el token de sesión se filtrase, bien mediante un ataque man in the middle en una conexión insegura, acceso físico el equipo, ingeniería social o cualquier otra técnica, se podría utilizar para impersonar al usuario legítimo durante el tiempo que dure la sesión.
Posibles acciones que mejorarían la seguridad de la sesión:
Un User-Agent es la firma que tiene el navegador web con el que nos comunicamos. Nuestros navegadores web envían en cada petición HTTP una cabecera en la que se indica la aplicación que está realizando la petición. Podemos visualizar las cabeceras enviadas bien mediante un analizador de tráfico de red como wireshark, una herramienta de auditoría como pueden ser Burp o ZAP o viendo las peticiones que realiza nuestro navegador directamente desde la pestaña network de las herramientas de desarrollo.
Otras aplicaciones hacen uso de la cabecera Authorization para enviar las credenciales de autorización o el token de intercambio cuando estas son necesarias. No obstante, si este token se inyecta en las peticiones realizadas por otro navegador, tendríamos la misma casuística que con las sesiones, un usuario podría hacer acciones en nombre de otro pero con la problemática adicional de que carecemos de las protecciones que los atributos de las cookies nos brindan. Esto conlleva a que el token de acceso de la aplicación podría verse filtrado ante una vulnerabilidad del tipo XSS por nombrar una de las casuísticas.
La sesión es una forma de proveer de un estado al protocolo HTTP. Asociado al identificador de sesión, es posible guardar temporalmente información adicional del usuario al que está enlazado. Hay veces en las que no es necesario guardar un estado de la interacción con la aplicación y simplemente se desean realizar acciones. Además, para obtener un token de sesión es necesario autenticarse previamente, lo que en el caso de aplicaciones automatizadas supondría por un lado guardar credenciales y por otro tener que gestionar los procesos de autenticación que sean necesarios.
Es por ello que muchas plataformas permiten la generación de un token de acceso que deberá guardarse de forma segura y que permitirá acceder a los recursos del usuario al que esté asociado, como si de una sesión se tratase del mismo. Algunas aplicaciones restringen los permisos del token de acceso generado en el momento de la creación del mismo. Aunque se pueden implementar caducidades, un token de acceso de aplicación generalmente no caduca y es siempre el mismo. (No confundir con el token de autorización de acceso a recursos generado por un proveedor de OAuth, que es distinto cada vez que se genera o renueva). Al igual que el token de sesión, si este token sufriera de una filtración el atacante que dispusiera de este podría realizar las acciones que le brinde el token.
Aunque no tiene por qué, este token suele mandarse en la cabecera Authorization. Un caso de uso sería el de por ejemplo, Linode, que permite la generación de tokens de aplicación para hacer uso de su API y desplegar máquinas en la nube.
En este escenario, una medida de seguridad interesante a adoptar sería la de restringir el uso del token de aplicación generado, a una dirección IP siempre que se pueda.
Existen otros tipos de token como por ejemplo JWT; que dispone de la información en claro firmada de forma criptográfica dentro del propio token para evitar que sea manipulada. No obstante, la explicación y los usos de estos excede el alcance de dicho artículo.
La expedición de tokens, que son un mecanismo de identificación de un usuario de cara a una aplicación, viene precedida por una autenticación inicial. Esta autenticación inicial es la utilizada para la generación del token y es un reto por el que el usuario deberá probar ser quien dice ser. Idealmente el reto inicial debe proveer de 3 elementos para probar la identidad del usuario.
Estos tres elementos pueden traducirse de la siguiente forma:
Cada elemento dota de una capa adicional de seguridad y aunque no se puedan aplicar todos en todas la ocasiones, conviene reforzar el reto de identificación mediante el uso de algunas de las siguientes técnicas:
Aunque consigamos proteger nuestro reto, esto no nos exime de las acciones que un atacante pueda realizar a nuestros usuarios. Un sistema es tan fuerte como su eslabón más débil y si nuestros usuarios cayesen en un ataque de phishing, podrían filtrar sus credenciales a un cibercriminal sin saberlo. Muchas páginas de phishing realizan una redirección al sitio web original, después de obtener los datos que desean. Esta acción a veces pasa desapercibida para el usuario que inicia sesión en el sitio web original y accede a su cuenta sin darse cuenta de que antes estaba introduciendo sus credenciales en otro sitio.
La redirección al sitio original se puede hacer de diversas técnicas. En algunas de ellas el navegador web de la víctima enviará la cabecera Referer apuntando al sitio que contiene phishing desde el que se ha realizado la redirección. Monitorizando las cabeceras de Referer que envían los navegadores web, podemos encontrar sitios fraudulentos que redirijan a la plataforma que se desea proteger.