Causar la denegación de servicio por "Spaming de sesión"

Question

Causar la denegación de servicio por "Spaming de sesión"

#1 de Anders (9 votos)
#2 de symcbean (2 votos)
#3 de Mark (1 votos)
#4 de Sunil Agrawal (0 votos)

4

Supongamos que tiene un inicio de sesión único en el ticket e inicia sesión en un sitio web que lo autentica por el ticket (lo mismo con el usuario / contraseña). El servidor web creará una sesión y el usuario almacenará el ID de sesión en su navegador. Ahora el usuario borra su cookie de sesión y actualiza el sitio. El usuario obtendrá otra sesión. Pero el servidor web tiene dos sesiones ahora. La sesión anterior no caduca hasta que se alcanza el tiempo de espera. Imagina que el usuario hará esto una y otra vez:

while(true) {
  open website
  delete cookie
}

Tan pronto como se alcance el máximo de sesiones en el servidor, nadie podrá crear otra sesión. La consecuencia es una denegación de servicio.

¿Cómo se llama este tipo de ataque?
¿Cómo puedo prevenirlo?
¿Qué tan alto es el riesgo en un escenario del mundo real? (El atacante todavía necesita una autenticación válida).

authentication denial-of-service session-management

pregunta licklake 15.12.2016 - 09:55

fuente

4 respuestas

9

Si está utilizando un buen sistema para generar ID de sesión, esto no sería un problema. Para evitar que un atacante adivine los ID de sesión mediante forzados brutos, debe tener un espacio muy grande, de modo que en la práctica haya muchos ID posibles para realizar este ataque.

Un atacante que sea capaz de llenar todo el espacio de ID de sesión disponible podría suplantar a cualquier usuario que haya iniciado sesión por medio de un bruto forzando su ID de sesión, algo mucho peor que DoS. Por lo tanto, para protegerse contra un riesgo mucho mayor, los sistemas sanos ya utilizan identificadores de sesión con suficiente entropía para hacer esto prácticamente imposible.

Por ejemplo, incluso si la ID de la sesión tiene solo 32 bits de entropía y una sesión dura todo un día, todavía necesitaría iniciar 100 mil millones de sesiones nuevas por segundo para aprovecharlas todas. De todos modos, eso sería suficiente para hacer que el servidor se quede solo al tráfico, por lo que el número limitado de posibles ID de sesión no sería el cuello de botella.

Otro ejemplo son ID de sesión de PHP . Por defecto, se generan mediante el hash MD5 una serie de cosas, incluida la hora actual. Entonces, a menos que golpee una colisión de hash por accidente (extremadamente improbable) no habrá duplicados.

Además de esto, supongo que la mayoría de los servicios tienen algún tipo de límite en el número de sesiones abiertas para un usuario o una IP.

Dado que este no es un ataque práctico, no creo que tenga un nombre, pero sería una forma de rechazar el servicio. Creo que lo bautizaron con un buen nombre en su título.

respondido por el Anders 15.12.2016 - 10:14

fuente

1

El servidor web creará una sesión y el usuario almacenará el ID de sesión en su navegador. Ahora el usuario borra su cookie de sesión y actualiza el sitio. El usuario obtendrá otra sesión. Pero el servidor web tiene dos sesiones ahora.

Si estás preocupado por esto, lo lógico es limitar la cantidad de sesiones simultáneas que un usuario puede tener. Un sitio web que visito con sesiones que requieren un uso intensivo de recursos hace precisamente eso: se le permite iniciar sesión desde tres navegadores a la vez. Inicie sesión desde un cuarto, y la sesión más antigua caducará.

Establezca la cantidad de sesiones según el uso esperado, por ejemplo. Una sesión para el escritorio de su hogar, una para el escritorio de su trabajo, otra para su computadora portátil o teléfono inteligente y algunos extras para situaciones inesperadas.

respondido por el Mark 22.12.2016 - 23:13

fuente

0

Es muy fácil llevar a cabo este tipo de ataque, usando curl o wget.

En uno de los proyectos en los que trabajé, usamos un caché de sesiones LRU (usado menos recientemente) por usuario, y configuramos el tamaño del caché LRU en 10. Por lo tanto, asumiendo que el atacante está usando el mismo nombre de usuario / contraseña, No ocupará más de 10 espacios. Esto funcionó muy bien para nosotros.

respondido por el Sunil Agrawal 21.12.2016 - 06:44

fuente

Lea otras preguntas en las etiquetas authentication denial-of-service session-management

¿Qué se puede hacer para proteger las contraseñas que se pueden almacenar en texto sin formato o con hash dentro de un repositorio de git? ¿Puede CloudFlare ser DDoS-ed y no puede ser el límite real de mitigación DDoS, los recursos financieros?

score 2 · Accepted Answer

Como dice Anders, la posibilidad de que un atacante ocupe todo el espacio de nombres de ID de sesión no es un problema. Sin embargo, hay otros cuellos de botella que podrían ser explotados. Los obvios son la capacidad de almacenamiento de sesión y el impacto de un número creciente de conjuntos de datos de sesión en el costo de recuperación de un solo conjunto de datos.

Aunque los datos de la sesión son pequeños, ya que hay un gran beneficio en el rendimiento al almacenar los datos de la sesión en la memoria, la cantidad de espacio asignado para el almacenamiento de la sesión puede ser del orden de Mb / host en lugar de Gb / host que uno podría esperar para el almacenamiento no volátil. En los clústeres, puede haber cuellos de botella en el ancho de banda de replicación. Los sistemas de archivos más antiguos pueden disminuir la velocidad al eliminar la referencia de archivos en un directorio con miles de entradas.

¿Cómo se llama este tipo de ataque?

No tengo idea (es un tipo de denisal de servicio, dirigido a recursos limitados)

¿Cómo puedo prevenirlo?

Asegúrese de tener más capacidad para el almacenamiento de su sesión de la que cree que necesita. Si la administración de su sesión no elimina de forma sincrónica los datos al vencimiento, entonces asegúrese de tener una recolección de basura agresiva.

RTFM: el controlador predeterminado de PHP, por ejemplo, tiene una opción para distribuir datos de sesión en varios directorios.

Supervise sus sistemas.

¿Qué tan alto es el riesgo en un escenario del mundo real? (El atacante todavía necesita una autenticación válida).

Yo diría que es posible, pero nunca se ha oído hablar de que suceda en la práctica. Si un sitio en particular es vulnerable? Haz los cálculos, por ejemplo. digamos que usa memcache para el almacenamiento de su sesión, tiene 500 Mb asignados para almacenamiento, un TTL de sesión de 1 hora y un tamaño de sesión promedio de 0.2 Mb, lo que significa que para completar el almacenamiento un atacante necesitaría crear 2500 sesiones en una hora, o un Nueva sesión cada 1.5 segundos - eso es factible. OTOH, con un tamaño de sesión de 0.02Mb, 4Gb de almacenamiento y un TTL de 10 minutos, necesitarían crear más de 300 sesiones por segundo, lo que se está volviendo difícil, especialmente si considera el ancho de banda necesario.