¿Qué es la autenticación rota? Ejemplos y cómo evitarlo

Los incidentes de violación de datos han ido en aumento en los últimos dos años. Según el informe IBM 2022, el coste mundial de la violación de datos ha ascendido a 4,35 millones de dólares, mientras que Estados Unidos ocupa el primer lugar con un coste medio de violación de datos cercano a los 9,5 millones de dólares. Los piratas informáticos siguen utilizando viejos métodos e inventando nuevas técnicas para obtener datos confidenciales de los consumidores.

Una forma de infiltrarse en un sistema es sondear diferentes vulnerabilidades de autenticación. Una autenticación defectuosa depende a menudo de otros ataques como la ingeniería social, el phishing, el man-in-the-middle o el cross-site scripting.

En este artículo, explicaremos qué comportamientos de los usuarios y errores de los desarrolladores conducen a una autenticación rota y compartiremos estrategias efectivas para prevenirla.

¿Qué es la autenticación rota?

Antes de sumergirnos en la autenticación rota, definamos primero la autenticación. En esencia, la autenticación es la verificación de la identidad del usuario mediante la solicitud de alguna información privada conocida sólo por este usuario, como su ID de usuario, correo electrónico y contraseña, o un escaneo de huellas dactilares.

La autenticación rota es una vulnerabilidad web que permite a los hackers saltarse los controles de autenticación, robar la identidad de alguien para iniciar sesión o romper otros mecanismos de seguridad. La autenticación rota puede deberse tanto a una gestión negligente de las credenciales como a una mala gestión de las sesiones.

Ejemplos de mala gestión de credenciales

Utilizar las credenciales de otra persona es una de las formas más comunes que tienen los malos actores de acceder a un sistema. En 2022, las credenciales robadas fueron el principal vector de ataque en el 19% de las brechas del estudio 2022 de IBM. Y no es de extrañar.

En primer lugar, mucha gente utiliza contraseñas débiles, y no estamos hablando de “123”, nombres de mascotas “admin” y fechas de nacimiento, aunque millones de usuarios todavía las utilizan. Y no exageramos: los datos que figuran a continuación hablan por sí solos.

Además, los estudios demuestran que el 44% de los consumidores cambia su contraseña una vez cada dos por tres. Esto significa que los hackers pueden lanzar ataques de fuerza bruta y de pulverización de contraseñas y robar credenciales con poco esfuerzo.

Los ataques de fuerza bruta están automatizados y se basan en un sencillo método de ensayo y error. La pulverización de contraseñas es un tipo de ataque de fuerza bruta. Sin embargo, en lugar de probar numerosas contraseñas en una sola cuenta, utiliza la misma contraseña para varios usuarios. Esto último permite a los hackers eludir el bloqueo de cuentas tras un determinado número de intentos fallidos de inicio de sesión.

Otro grupo de personas utiliza el mismo correo electrónico y contraseña en todas sus cuentas. Según Statista, sólo el 12% de los usuarios crearon siempre nuevas contraseñas al registrar nuevas cuentas en 2021, mientras que el 45% reutilizó siempre o casi siempre contraseñas antiguas.

Esto dio lugar a los ataques de robo de credenciales. La darknet está repleta de correos electrónicos filtrados y contraseñas de distintas organizaciones. Como la gente utiliza las mismas contraseñas para varias aplicaciones, los atacantes pueden utilizar las credenciales obtenidas de la darknet y probarlas para los sitios objetivo. El relleno de credenciales es también un ataque automatizado, lo que significa que supone un esfuerzo mínimo para los hackers.

Pero los usuarios no son los únicos culpables en este caso; también puede haber errores por parte de los desarrolladores. Por ejemplo, las contraseñas pueden almacenarse en texto plano o utilizar hashes débiles, lo que facilita a los hackers descifrarlas con tablas rainbow.

¿Por qué es importante la gestión de sesiones?

La gestión de sesiones es una parte integral de las aplicaciones web modernas. Una sesión web es una secuencia de peticiones y respuestas HTTP en red pertenecientes a un mismo usuario. Las aplicaciones web utilizan las sesiones para conservar información sobre un usuario concreto y responder adecuadamente a todas sus acciones y peticiones mientras dure la sesión.

Por ejemplo, cuando un usuario navega por primera vez por el sitio, sus preferencias de idioma se guardarán durante toda la sesión, lo que mejora la usabilidad.

Las sesiones también son útiles después de la autenticación. Una vez que el usuario se ha autenticado, la aplicación web podrá identificarlo durante las interacciones posteriores y aplicar los controles de seguridad correspondientes.

Una vez creada una sesión, se asigna al usuario un identificador de sesión o token temporalmente equivalente al método de autenticación más fuerte e intercambiado por el usuario y la aplicación web durante la sesión.

Ejemplos de autenticación rota y gestión de sesiones

La correcta implementación de la sesión juega un papel tremendo en la prevención de vulnerabilidades de autenticación. He aquí algunos ejemplos de cómo una gestión incorrecta de la sesión conduce a una autenticación defectuosa.

Secuestro de sesión. Puede adoptar muchas formas. El ejemplo más sencillo de secuestro de sesión es cuando un usuario no invalida su sesión en un ordenador público: puede cerrar sólo las ventanas del navegador sin cerrar la sesión de las aplicaciones. En este caso, la persona que coja el mismo ordenador después podría hacerse pasar fácilmente por ese usuario porque la sesión sigue activa y las apps están desbloqueadas.

Pero los hackers no se limitan a ir a espacios públicos a probar suerte. La mayoría de sus ataques se planean de antemano y se realizan a distancia. Otra forma de secuestrar una sesión consiste en espiar el tráfico de la red utilizando rastreadores de paquetes como Wireshark. Si las aplicaciones web utilizan el cifrado TLS sólo en las páginas de inicio de sesión, los hackers pueden vigilar el tráfico en otras páginas y robar las cookies de sesión.

Los delincuentes también podrían intentar robar el testigo de sesión mediante secuencias de comandos en sitios cruzados (XSS). Básicamente, crean un enlace con un código especial que se ejecutará al hacer clic en él. El script puede estar escrito en JavaScript o en cualquier otro lenguaje del lado del cliente. He aquí un ejemplo de script malicioso que revelará el valor de la cookie en una ventana emergente:

<SCRIPT>

alert(document.cookie);

</SCRIPT>

Fijación de sesión. En un ataque de fijación de sesión, el hacker se conecta a la aplicación web para obtener un identificador de sesión válido y luego engaña a un usuario legítimo, ya sea mediante ingeniería social o un sitio de phishing, para que se autentique con ese identificador de sesión. De este modo, si la aplicación no renueva el identificador de sesión tras la autenticación, el hacker puede hacerse pasar por el usuario y acceder a su cuenta.

He aquí un ejemplo de enlace malicioso que cambiará el valor del identificador de sesión de la víctima en su cookie si hace clic en él:

http://website.com/<script>document.cookie=”sessionid=abcd”;</script>

Reescritura de URL con ID de sesión. Si una aplicación web inserta el identificador de sesión en la URL en lugar de almacenarlo en la cookie, lo expone y permite que cualquiera que siga la URL herede la sesión. Así, si una URL de este tipo se comparte por error, otro usuario puede hacerse cargo de la sesión sin necesidad de autenticarse.

Empresas afectadas por la autenticación defectuosa

Veamos ejemplos reales de empresas que sufrieron filtraciones de datos debido a la mala gestión de credenciales u otras vulnerabilidades de autenticación.

Revolut es una aplicación para enviar fondos, solicitar pagos y dividir facturas en más de 200 países. En septiembre de 2022, Revolut sufrió una filtración de datos que dejó al descubierto nombres, correos electrónicos, números de teléfono, direcciones postales, detalles de dispositivos, historial de transacciones y las últimas direcciones IP conocidas de unos 50.000 usuarios.

Aunque los datos de las tarjetas de débito y crédito estaban enmascarados y eran inutilizables, la información robada puede utilizarse para el robo de identidad y ataques de phishing. Los investigadores creen que la base de datos fue comprometida por un empleado que fue víctima de un ataque de ingeniería social meticulosamente elaborado y entregó las credenciales de acceso a los hackers.

Twilio es una plataforma de captación de clientes que proporciona API de comunicación para canales de SMS, voz y vídeo. Twilio sufrió una brecha en agosto de 2022; los hackers accedieron a los datos de 125 clientes de Twilio. Entre las víctimas secundarias de la brecha se encontraban grandes nombres como Signal y Okta. Una vez más, el ataque se realizó engañando a los empleados para que siguieran una URL de phishing desde SMS, supuestamente para actualizar contraseñas caducadas o ver cambios de programación.

Twitter, una de las mayores redes sociales del mundo, también fue pirateada en 2022. Lo que ocurrió es que la actualización de su código en junio de 2021 provocó la siguiente vulnerabilidad: cuando los hackers enviaban un correo electrónico o un número de teléfono al sistema de Twitter, el sitio revelaba la cuenta de Twitter asociada a ese número de teléfono o correo electrónico. Como resultado, se revelaron los datos personales de 200 millones de usuarios, lo que puede dar lugar a fraudes de phishing o robos de identidad en el futuro.

Crypto.com es una bolsa de criptomonedas que perdió unos 30 millones de dólares en Bitcoin y Ethereum. Su sistema de autenticación de dos factores resultó ser lo suficientemente débil como para que los hackers pudieran burlarlo. Los piratas informáticos consiguieron retirar fondos de 483 cuentas de clientes. La empresa tiene la intención de sustituir la autenticación de dos factores por una multifactor para frenar este tipo de incidentes en lo sucesivo.

LastPass es un gestor de contraseñas que permite almacenar y compartir contraseñas y otros documentos valiosos. Fue violada dos veces. La primera vez, los piratas informáticos robaron parte del código fuente y cierta información técnica confidencial a través de una cuenta de desarrollador comprometida. La segunda vez robaron las contraseñas de los clientes. Aunque estas últimas están cifradas, los hackers pueden forzar las contraseñas maestras que las bloquean.

Cómo evitar una autenticación incorrecta

La mejor forma de evitar una autenticación incorrecta es aplicar un enfoque de seguridad multicapa. Repasemos los elementos esenciales que te ayudarán a conseguirlo.

Añadir autenticación multifactor

La autenticación multifactor (AMF) es una capa de seguridad adicional que requiere que el usuario presente otra prueba para iniciar sesión. Puede ser un PIN, un código enviado al teléfono o al correo electrónico, una huella dactilar, un escáner facial o del iris, o una contraseña de un solo uso basada en el tiempo (TOTP) de una aplicación de autenticación respectiva.

Microsoft cree que la incorporación de MFA habría detenido el 99,9% de los ataques automatizados relacionados con contraseñas. Sin embargo, la MFA tiene varias desventajas: reduce la usabilidad, añade dependencias externas al sistema y no ofrece una forma fácil de restablecerla sin anular su propósito.

Como salida, la MFA puede implementarse sólo para administradores y usuarios con derechos de alto privilegio o sólo para transacciones de alto impacto. La forma en que debe implantarse la AMF depende de factores como el modelo de amenazas de la aplicación, los conocimientos tecnológicos de los usuarios, el grado de control administrativo sobre los usuarios y los gastos generales.

Añadir CAPTCHA

CAPTCHA es la abreviatura de Completely Automated Public Turing Test to Tell Computers and Humans Apart. En términos sencillos, es una comprobación rápida para distinguir a los humanos de los bots.

Los CAPTCHA originales requerían que el usuario adivinara los caracteres y números distorsionados y superpuestos y los introdujera en el campo de entrada. A medida que los bots se volvían más inteligentes en el reconocimiento de patrones, surgió la necesidad de pruebas más intrincadas basadas en imágenes.

Sin duda, los CAPTCHA añaden fricción al recorrido del usuario, por lo que tiene sentido utilizarlos sólo después de un par de intentos fallidos de inicio de sesión.

Aunque CAPTCHA hace que los ataques de fuerza bruta resulten incómodos y más costosos, no puede garantizar una protección del 100% contra ellos.

Almacenar contraseñas de forma segura

Seguramente todo el mundo habrá oído alguna vez que las contraseñas nunca deben almacenarse en texto plano, ya que las bases de datos se ven comprometidas constantemente. Por tanto, aunque un pirata informático acceda a la base de datos, su contenido permanecerá codificado.

Los desarrolladores pueden conseguirlo con algoritmos hash modernos. El hashing, a diferencia del cifrado, es una función unidireccional, por lo que no se puede descifrar.

Al mismo tiempo, siguen existiendo soluciones como calcular los hashes de las contraseñas más utilizadas y compararlos con los hashes de la base de datos violada. Para dificultar el trabajo de los piratas informáticos, los hashes de contraseñas deben tener sal, lo que significa que a los hashes se les añade una cadena generada aleatoriamente y única para cada usuario.

Los hashes de contraseñas con sal tardan mucho más tiempo en descifrarse y hacen imposible saber si dos usuarios tienen la misma contraseña, ya que diferentes sales dan lugar a diferentes hashes, independientemente de si las contraseñas de los usuarios son idénticas.

Aplique políticas de contraseñas seguras

¿Qué se considera una contraseña segura? Según el Instituto Nacional de Estándares y Tecnología, las contraseñas deben tener al menos 8 caracteres y no contener caracteres repetitivos o secuenciales (como aaaa o abc123). Además, los usuarios deben poder elegir entre todos los caracteres, incluidos Unicode y los espacios en blanco.

Pero ese es el umbral más bajo, y usted no quiere estar en lo más bajo cuando se trata de seguridad. El Estándar de Verificación de Seguridad de Aplicaciones OWASP exige que las contraseñas tengan al menos 12 caracteres, mientras que los desarrolladores de medidores de seguridad de contraseñas como Bitwarden sugieren entre 14 y 16 caracteres.

En general, cuanto más larga sea la contraseña, mejor, porque aumenta el número de combinaciones que una red de bots necesita para descifrarla. Pero ten en cuenta que los caracteres deben generarse aleatoriamente.

Algunos sitios web limitan el número de caracteres que puedes utilizar, así que otra forma de añadir complejidad a tu contraseña es utilizar mayúsculas, caracteres especiales y números. De nuevo, la aleatoriedad es un factor clave a la hora de añadirlos. Por ejemplo, “Logmein!321” es un patrón de contraseña terrible, mientras que “l_w4XgH9~Wiq” es lo que estamos intentando conseguir.

El formulario de inicio de sesión debe tener un medidor de seguridad de contraseñas integrado, que compruebe las contraseñas con palabras del diccionario, contraseñas violadas anteriormente o palabras específicas del contexto, como el nombre del servicio o del usuario y sus derivados.

Cuando introduzca políticas de caducidad de contraseñas, recuerde que los empleados tienden a cambiar sólo un carácter para acabar de una vez y seguir con sus tareas diarias. Por lo tanto, es importante educar a los empleados sobre lo que hace que una contraseña sea segura y solicitar el cambio de contraseña sólo si hay una sospecha o un compromiso real. Como los hackers no se quedan con las credenciales expuestas, actúan de inmediato.

Crear contraseñas seguras para numerosos servicios y almacenarlas de forma segura es, sin duda, una carga adicional sobre los hombros de los empleados. Por lo tanto, las organizaciones deben proporcionar un método sancionado para generar y almacenar las contraseñas corporativas, ya sea un almacenamiento físico, un software de gestión de contraseñas o una combinación de ambos, y definir claramente las acciones de los empleados en diferentes escenarios.

De lo contrario, los empleados seguirán utilizando contraseñas débiles y fáciles de recordar e improvisarán con el almacenamiento, guardando las contraseñas en teléfonos personales o borradores de Gmail.

Para evitar ataques de denegación de servicio con contraseñas largas, debe fijarse la longitud máxima de la contraseña, que suele ser de 64 caracteres.

Mejorar el umbral de bloqueo de cuentas

El bloqueo de una cuenta es un arma de doble filo. Por un lado, es una de las protecciones más comunes y eficaces contra los ataques de fuerza bruta, ya que la cuenta simplemente se bloquea después de un cierto número de intentos fallidos.

Por otro lado, el bloqueo de cuentas puede crear fácilmente una situación de denegación de servicio. Los piratas informáticos pueden lanzar ataques automatizados contra todos los usuarios de una organización, creando bloqueos masivos de cuentas e inundando a los equipos de atención al cliente con llamadas de los usuarios. El coste del tiempo de inactividad y los riesgos para la reputación serían tremendos.

Otro escenario es cuando un usuario tiene prisa o está agitado y escribe mal su correo electrónico o contraseña un par de veces. Si el umbral de bloqueo de la cuenta es demasiado bajo, puede desencadenar un bloqueo accidental.

Por desgracia, no existe una solución milagrosa para resolver el dilema del bloqueo de cuentas. Es responsabilidad de cada empresa encontrar un término medio entre seguridad y eficacia operativa. Al definir el umbral de bloqueo de cuentas, es importante calcular cuántos intentos pueden realizar los atacantes al día y ralentizarlos ajustando el umbral de bloqueo de cuentas, la duración y la configuración de restablecimiento en consecuencia.

Mostrar errores genéricos

La gestión de errores es otro margen para que los actores maliciosos recopilen información y se introduzcan. Si los mensajes de error son muy específicos, facilitan enormemente el trabajo de los hackers, ya que sabrán exactamente qué ha fallado, qué tecnologías y versiones de framework se han utilizado y podrán planificar su ataque en consecuencia.

Por ejemplo, si un malhechor intenta iniciar sesión con las credenciales de otra persona y ve el mensaje “Error de inicio de sesión; cuenta desactivada”, no perderá el tiempo y buscará otra cuenta. O peor aún, el nombre del usuario puede revelarse en el propio mensaje, como “Inicio de sesión para el usuario Boo: contraseña no válida”.

Por eso es mejor mostrar mensajes de error genéricos para el registro, el inicio de sesión de un usuario existente y la recuperación de la contraseña.

Otro aspecto a tener en cuenta es el tiempo de procesamiento. Debe ser el mismo independientemente del resultado para que el hacker no pueda realizar un ataque basado en el tiempo.

Por ejemplo, cuando se utiliza el enfoque de “salida rápida”, la aplicación arrojará rápidamente un error si el usuario no existe. Sin embargo, si el usuario existe, pero la contraseña es incorrecta, la aplicación seguirá más pasos y tardará más en responder. Esto permite al hacker diferenciar entre un nombre de usuario y una contraseña incorrectos basándose en el tiempo de respuesta al error.

También es crucial asegurarse de que no se filtra información a través de la URL. La aplicación puede devolver un mensaje genérico al usuario, pero un código de error HTTP diferente en función de si el inicio de sesión se ha realizado correctamente (200 OK) o no (403 Forbidden).

Aunque los mensajes genéricos dificultan el reconocimiento a los piratas informáticos, pueden confundir a los consumidores y afectar negativamente a la adopción de la aplicación y a la retención de usuarios. Por tanto, encontrar un equilibrio entre usabilidad y seguridad es algo que cada empresa debe definir por sí misma.

Olvídese de las preguntas de seguridad

Las preguntas de seguridad ya no se consideran un mecanismo de autenticación aceptable. También hay que tener en cuenta que el uso de una contraseña en combinación con una pregunta de seguridad no equivale a la AMF porque el factor en ambos casos es el mismo: algo que sabes.

Hay dos tipos de preguntas de seguridad: las definidas por el usuario y las definidas por el sistema, y ambas son fáciles de vulnerar. Echemos un vistazo a las preguntas de seguridad definidas por el usuario más comunes y por qué son malas:

Por supuesto, se pueden plantear preguntas más complejas como “¿Cómo se llama la universidad a la que te inscribiste pero no fuiste?” o “¿Cómo se apellidaba tu profesor de matemáticas de séptimo curso?”. Pero ¿está seguro de que todos los usuarios las recuerdan bien? Una solución aquí es proporcionar una lista de preguntas para elegir, pero aun así, no hay garantía de que las respuestas no se predigan.

Ya en 2015, la investigación de Google confirmó que las preguntas de seguridad o son seguras o son fáciles de recordar, pero nunca ambas cosas. Mientras que el 40% de los usuarios no podía recordar las respuestas a su pregunta de seguridad, el 37% proporcionaba respuestas falsas deliberadamente, tratando de hacerlas más difíciles de adivinar pero consiguiendo exactamente lo contrario.

En cuanto a las preguntas definidas por el sistema, se basan en la información ya registrada en el sistema, como el nombre, la fecha de nacimiento o la dirección del usuario. Estos últimos, sin embargo, también pueden descubrirse a través de las redes sociales o de vertederos de la web oscura.

Actualice sus marcos de trabajo

Implementar un módulo de gestión de sesiones seguro es todo un reto, ya que combina autenticación, tráfico HTTP de usuario y controles de acceso aplicados por la aplicación web. Por eso se recomienda utilizar las funciones integradas de gestión de sesiones y las guías de implementación que ofrecen los frameworks más conocidos, en lugar de codificarlas por tu cuenta.

Al mismo tiempo, incluso los frameworks ampliamente adoptados y bien probados pueden contener vulnerabilidades. Por lo tanto, asegúrate de utilizar las últimas versiones de los frameworks que tengan correcciones para vulnerabilidades conocidas. Además, cambia la configuración por defecto para mejorar la seguridad de tu aplicación.

Generar ID de sesión segura

El nombre del identificador de sesión por defecto puede revelar las tecnologías y lenguajes de programación utilizados por la aplicación web. Por ejemplo, PHPSESSID es indicativo de PHP, JSESSIONID es generado por J2EE, mientras que CFID & CFTOKEN sugiere que la aplicación está construida con ColdFusion. Por lo tanto, el nombre por defecto debe cambiarse por algo genérico y no muy descriptivo.

La longitud del identificador de sesión es importante. Al igual que las contraseñas, debe ser lo suficientemente largo para evitar ataques automatizados; OWASP recomienda al menos 128 bits; sin embargo, este número no es rígido y deben tenerse en cuenta otros detalles de implementación.

El identificador de sesión también debe tener una entropía efectiva. En otras palabras, debe ser aleatorio e impredecible para resistir técnicas de análisis estadístico. Esto se puede conseguir con un CSPRNG (Cryptographically Secure Pseudorandom Number Generator) fiable.

Los objetos y propiedades de la sesión, como la dirección IP del usuario, su correo electrónico, sus derechos de acceso o su último inicio de sesión, deben almacenarse en el servidor en una base de datos o repositorio de gestión de sesiones protegido.

Por último, pero no por ello menos importante, el identificador de sesión debe ser único, lo que significa que una sesión actual no puede contener identificadores duplicados.

Elegir el mecanismo adecuado de intercambio de identificadores de sesión

La aplicación web y el usuario necesitan un mecanismo determinado para compartir e intercambiar el identificador de sesión. Hay varias formas de hacerlo: con cookies, parámetros de URL, argumentos de URL en peticiones GET o argumentos de cuerpo en peticiones POST.

Cuando elijas un mecanismo de intercambio de ID de sesión adecuado, comprueba si permite definir propiedades avanzadas de los tokens, como fecha y hora de caducidad, y políticas de uso granulares. Las cookies HTTP son algunos de los mecanismos de intercambio de ID de sesión más utilizados porque ofrecen estas capacidades y otras más.

Los parámetros URL, por otro lado, se consideran un mecanismo de intercambio de ID de sesión obsoleto, ya que pueden revelar el ID de sesión en la URL y permitir a los hackers realizar ataques de fijación de sesión u otras manipulaciones de ID.

Otro punto a tener en cuenta es que, aunque la aplicación utilice cookies por defecto, puede aceptar otros mecanismos de intercambio o cambiar de cookies a parámetros de URL en determinadas condiciones. Por lo tanto, es necesario realizar pruebas rigurosas para definir cómo la aplicación procesa y gestiona los identificadores de sesión en diferentes escenarios y garantizar que se basa exclusivamente en cookies.

Implementar controles contra las escuchas

Los identificadores de sesión pueden ser interceptados o robados espiando el tráfico de red. Para evitar que esto ocurra, las aplicaciones web deben implementar la protección de la capa de transporte.

Transport Layer Security (TLS) es uno de los protocolos más modernos para cifrar la comunicación entre una aplicación web y un servidor.

Naturalmente, los desarrolladores web deberían utilizar la última versión de TLS porque es más rápida y menos vulnerable que sus predecesoras; en el momento de escribir estas líneas, es TLS 1.3.

TLS debe aplicarse a todas las páginas, independientemente de su sensibilidad. De lo contrario, se proporciona un resquicio para que un mal actor espíe los tokens de sesión o inyecte código JavaScript malicioso para ejecutar otros ataques. Por las mismas razones, no debe haber mezcla de contenido TLS y no TLS. Las páginas disponibles a través de TLS no pueden contener ningún archivo JavaScript o CSS cargado a través de HTTP inseguro.

Aunque TLS protege los datos en tránsito, no protege los datos que han llegado al sistema, como los almacenados en la caché del navegador del usuario.

Renovar el ID de sesión tras un cambio de privilegios

Es esencial asegurarse de que tu aplicación web no utiliza un token previamente asignado cuando cambia el nivel de privilegios del usuario. Por ejemplo, cuando el usuario pasa de ser un usuario normal a un administrador o superusuario, la aplicación debería ignorar los ID de sesión antiguos y generar uno actual.

OWASP también recomienda asignar un ID de sesión diferente cuando el usuario pasa de ser un visitante anónimo a uno autenticado. Esto último ayuda a eliminar el riesgo de ligar la sesión del usuario entre ambos estados. La regeneración del ID de sesión es vital para prevenir ataques de fijación de sesión.

Establecer el tiempo de caducidad de la sesión

Los tiempos de expiración de sesión son útiles porque limitan el tiempo que tiene un mal actor para secuestrar la sesión. Por tanto, cuanto más corta sea la duración de la sesión, mejor. Por eso, las aplicaciones muy sensibles sólo ofrecen de 2 a 5 minutos antes de que el usuario tenga que volver a autenticarse.

Por supuesto, el intervalo de expiración de la sesión depende de la naturaleza de la aplicación y de los casos de uso reales. Si hablamos de un empleado de oficina, necesitará 8 horas de sesión activa, siempre que todas sus tareas estén relacionadas con la interacción con la aplicación.

Hay varios tipos de tiempos de espera, como los inactivos, los absolutos y los de renovación. Los tiempos de espera inactivos se aplican cuando no hay nueva actividad después de un tiempo determinado. Los tiempos de espera inactivos están pensados para acortar el tiempo en el que un hacker puede adivinar un ID de sesión válido. Por otro lado, si la sesión ya está secuestrada, el atacante puede crear periódicamente alguna actividad para prolongar la sesión.

Los tiempos de espera absolutos establecen el tiempo máximo que una sesión puede estar activa, cerrándose automáticamente al expirar. Durante los tiempos de espera de renovación, se genera un nuevo ID de sesión en mitad de la sesión actual independientemente de la actividad del usuario, y el ID anterior se invalida en cuanto el usuario envía una nueva solicitud.

Una vez alcanzado el límite de sesión, la aplicación web debe invalidar la sesión en el lado del cliente y del servidor para que el atacante no pueda manipular los parámetros del cliente para realizar un seguimiento del tiempo, como el número de minutos transcurridos desde el inicio de sesión.

Detectar y supervisar anomalías en las sesiones

Las aplicaciones web deben incorporar funciones de detección de anomalías para alertar a los usuarios de comportamientos inusuales o finalizar sesiones sospechosas. Estas son las cosas que indican una posible intrusión:

• se intentan diferentes ID de sesión desde la misma dirección IP de forma secuencial
• se elimina o modifica una cookie existente
• se añade una nueva cookie
• se reutiliza el identificador de sesión de otro usuario
• la ubicación del usuario cambia en mitad de una sesión

Las aplicaciones web deben registrar la información de sesión a lo largo de todo su ciclo de vida, desde la creación y renovación hasta la destrucción del identificador de sesión. También deben registrarse eventos como el inicio y el cierre de sesión, los intentos fallidos de inicio de sesión, los inicios de sesión simultáneos, los cambios de privilegios y las transacciones de alto impacto. El propio identificador de sesión debe registrarse como un hash salado.

En cuanto a las funciones de cara al cliente, los usuarios deben poder ver detalles sobre las sesiones activas, los dispositivos conectados y las direcciones IP. Deben recibir notificaciones sobre los inicios de sesión simultáneos y tener la oportunidad de finalizar las sesiones de forma remota en todos los dispositivos.

Sin contraseña

Si las contraseñas plantean tantos problemas, ¿por qué utilizarlas? Muchas empresas ya han adoptado o tienen intención de adoptar la autenticación sin contraseña. Según la encuesta de Bitwarden de 2022, el 41% de los 800 responsables de la toma de decisiones de TI cree que la autenticación sin contraseña mejora la seguridad, mientras que el resto destaca su efecto en el aumento de la productividad en el lugar de trabajo, la mejora de la experiencia del usuario y la reducción del servicio de asistencia.

Además, si su aplicación web se conecta a una aplicación de terceros, no querrá que esta última almacene las credenciales de inicio de sesión de los usuarios, ya que aumenta la posibilidad de que se produzcan infracciones y usted no tiene control sobre la seguridad de la aplicación de terceros. En este caso, la única opción es utilizar protocolos de autenticación sin contraseña.

Estos son algunos de los protocolos de autenticación más conocidos que no requieren contraseña.

• OAth 2.0: un marco de autorización de código abierto que permite a una aplicación de terceros obtener acceso limitado a un servicio HTTP. En lugar de depender de las credenciales del usuario, la aplicación de terceros recibe un token de acceso especial. OAth 2.0 es utilizado por grandes nombres como Meta, Google, Twitter y Microsoft.
• OpenID: tecnología descentralizada de código abierto que permite utilizar una cuenta para acceder a varios sitios web. Básicamente, compartes tus credenciales con un único proveedor de identidad en el que confías y luego inicias sesión con este proveedor de identidad sin revelar tus credenciales reales. Más de 50.000 sitios web aceptan OpenID para iniciar sesión.
• SAML – Lenguaje de marcado de aserción de seguridad. Al igual que OpenID, SAML permite acceder a varias aplicaciones web con un conjunto de credenciales de inicio de sesión. La diferencia es que está basado en XML, ofrece más flexibilidad y se adapta mejor a entornos empresariales.
• FIDO: siglas de Fast Identity Online. Los protocolos FIDO se basan en técnicas de criptografía de clave pública. Al registrarse en un sitio web, el dispositivo del usuario genera un par de claves, conservando la privada y registrando la pública en el servicio en línea. Para autenticarse, el usuario tiene que demostrar que posee la clave privada desbloqueándola localmente en su dispositivo mediante la introducción de un PIN, hablando por un micrófono, insertando un dispositivo de segundo factor, pasando el dedo, etc.

Invertir en pruebas de penetración

Las pruebas de penetración son un tipo de prueba que simula el ataque de un hacker en un entorno controlado. Los especialistas en pruebas de penetración utilizan una combinación de herramientas de seguridad, como escáneres de vulnerabilidades, y técnicas manuales empleadas por atacantes reales. Esto hace que las pruebas de penetración sean fundamentales para mejorar la postura de seguridad de una empresa.

Las pruebas de penetración son una parte indispensable de las normativas de cumplimiento como HIPAA, SOC 2 o PCI-DSS, lo que confirma su eficacia a la hora de descubrir brechas de seguridad y cerrarlas a tiempo.

En QAwerk ayudamos a las empresas de nueva creación y a las ya establecidas a probar a fondo sus módulos de autenticación, descubrir posibles amenazas y encontrar formas eficaces de parchear esas vulnerabilidades. Nuestra lista de comprobación de pruebas de penetración incluye todos los puntos mencionados y más, en función de las peculiaridades técnicas de su producto.

Además de un análisis dinámico de su aplicación, también podemos examinar el código fuente antes de un lanzamiento importante o de un nuevo producto para que pueda ofrecer nuevas funciones a los consumidores con total tranquilidad. Si desea obtener más información sobre cómo podemos ayudarle a proteger su software contra los piratas informáticos y cómo es nuestro proceso de pruebas de penetración, no dude en enviarnos un correo electrónico. Ofrecemos consultas gratuitas y sin compromiso para ver si somos la opción adecuada para sus necesidades.

Resumen

Los fallos de autenticación figuran entre las diez principales vulnerabilidades web clasificadas por OWASP. Aunque los fallos de identificación y autenticación se han reducido en los últimos dos años gracias a marcos estandarizados, siguen suponiendo un riesgo considerable y son explotados a diario por malos actores.

Alinear su aplicación con las mejores prácticas de seguridad para la gestión de credenciales y la gestión de sesiones, educar a los empleados en ingeniería social e higiene en línea, y realizar auditorías de seguridad periódicas por una parte cualificada le salvará de las violaciones de datos y las ramificaciones asociadas.