De Wikipedia, la enciclopedia libre
Ir a navegaciónSaltar a buscar

El envenenamiento de la sesión (también conocido como "contaminación de los datos de la sesión" y "modificación de la sesión") es un método para explotar la validación de entrada insuficiente dentro de una aplicación de servidor. Normalmente, una aplicación de servidor que es vulnerable a este tipo de exploit copiará la entrada del usuario en las variables de sesión .

La vulnerabilidad subyacente es un problema de gestión de estado: estado compartido, condición de carrera , ambigüedad en el uso o modificaciones simples y desprotegidas de los valores de estado.

El envenenamiento de la sesión se ha demostrado en entornos de servidor donde diferentes aplicaciones no maliciosas (scripts) comparten los mismos estados de sesión pero donde el uso difiere, lo que genera ambigüedad y condiciones de carrera.

El envenenamiento de la sesión se ha demostrado en escenarios en los que el atacante puede introducir secuencias de comandos maliciosas en el entorno del servidor, lo que es posible si el atacante y la víctima comparten un servidor web.

Orígenes

El envenenamiento de la sesión se analizó por primera vez como una clase de vulnerabilidad (potencialmente nueva) en la lista de distribución de información completa. [1] Alla Bezroutchko preguntó si las "vulnerabilidades de contaminación de datos de sesión en aplicaciones web" eran un problema nuevo en enero de 2006. Sin embargo, esta era una vulnerabilidad antigua que otros habían señalado anteriormente: "este es un problema clásico de gestión del estado" - Yvan Boily; [2] "Esto no es nuevo" - / alguien. [3]

Se pueden encontrar ejemplos anteriores de estas vulnerabilidades en los principales recursos / archivos de seguridad como Bugtraq , p. Ej.

  • Julio de 2001, Grave agujero de seguridad en Mambo Site Server versión 3.0.X por Ismael Peinado Palomo de reverseonline.com [4]
  • Septiembre de 2005, modificación de la sesión PHP por desconocido (de uw-team) y adam_i [5]

La contaminación de sesiones también se ha tratado en algunos artículos, como PHP Session Security, Przemek Sobstel, 2007. [6]

Ejemplos de ataques

Escenario de ataque trivial

Un código de ejemplo vulnerable a este problema es:

Sesión ("Iniciar sesión") = Solicitar ("iniciar sesión")
Sesión ("Nombre de usuario") = Solicitud ("nombre de usuario")

Que está sujeto a ataques triviales como

vulnerable.asp? login = YES & username = Mary

Este problema podría existir en el software donde

  • El usuario envía nombre de usuario / contraseña a logon.asp
  • Si la contraseña para los Marycheques, logon.aspreenvía avulnerable.asp?login=YES&username=Mary

El problema es que vulnerable.aspestá diseñado partiendo del supuesto de que solo se accede a la página de forma no maliciosa. Cualquiera que se dé cuenta de cómo está diseñado el script, puede crear una solicitud HTTP que establece el usuario de inicio de sesión arbitrariamente.

Explotación del uso ambiguo o dual de la misma variable de sesión

Alla Bezroutchko analiza un escenario en el que $_SESSION['login']se utiliza para dos propósitos diferentes. [7]

  • En los scripts de inicio de sesión, la variable de sesión almacena "Este usuario ha iniciado sesión".
  • En los scripts de restablecimiento de contraseña, la variable de sesión almacena "este usuario desea restablecer su contraseña".

Se demostró una condición de carrera, en la que los scripts de reinicio podrían explotarse para cambiar arbitrariamente al usuario que inició sesión.

Explotación de scripts que permiten escrituras en variables de sesión arbitrarias

Alla Bezroutchko analiza ejemplos observados en foros de desarrollo, lo que permite escribir en variables de sesión arbitrarias. [8]

El primer ejemplo es

$ var  =  $ _GET [ "algo" ];  $ _SESSION [ " $ var " ]  =  $ var2 ;

(en el que $ _GET ["algo"] es probablemente de un cuadro de selección o similar).

El ataque se convierte

vulnerable.php? algo = SESSION_VAR_TO_POISON

Ataques de envenenamiento de sesión habilitados por php.ini: register_globals = on

php.ini: register_globals = ones conocido por habilitar vulnerabilidades de seguridad en varias aplicaciones. Se recomienda a los administradores del servidor PHP que deshabiliten esta función.

Nota: Ejemplos del mundo real de envenenamiento de sesiones habilitado por register_globals = on se demostraron públicamente en el artículo de julio de 2001 Grave agujero de seguridad en Mambo Site Server versión 3.0.X. [9]

El segundo ejemplo de / someone es [10]

if  ( $ condición1 )  {  $ var  =  'ALGO' ;  };  if  ( $ condición2 )  {  $ var  =  'OTRO' ;  };  $ _SESSION [ " $ var " ]  =  $ var2 ;

que es vulnerable si:

  • Es posible que el atacante provoque que ambas condiciones sean falsas.
  • php.ini está mal configurado (register_globals = on), lo que permite que el valor predeterminado de $ var sea controlado por la entrada GPC (GET, POST o COOKIE).

El ataque se convierte

vulnerable.php? var = SESSION_VAR_TO_POISON

Explotar utilizando un servidor PHP compartido (por ejemplo, alojamiento web compartido)

'desconocido' de uw-team.org analiza un escenario en el que el atacante y la víctima comparten el mismo servidor PHP. [11]

El ataque es bastante fácil:

  • El atacante visita primero la página de la víctima y, por ejemplo, inicia sesión.
  • El atacante luego carga un script PHP en su cuenta y hace que muestre el contexto de $ _SESSION (establecido por el script de la víctima).
  • El atacante determina qué variable debe cambiarse, carga un script que establece esta variable y la ejecuta.
  • El atacante visita las páginas de la víctima para ver si la explotación anticipada funcionó.

Este ataque solo requiere que la víctima y el atacante compartan el mismo servidor PHP. El ataque no depende de que la víctima y el atacante tengan el mismo nombre de host virtual, ya que es trivial para el atacante mover la cookie de identificación de sesión de un dominio de cookies a otro.

Ver también

Referencias