Las páginas web tienen memoria, reconocen las acciones que el usuario ha realizado anteriormente como, por ejemplo, si se ha registrado, qué elementos ha visitado o las compras añadidas a la cesta. Dicho de otro modo, establecen una sesión con el internauta.
Si HTTP, el protocolo con el que se interactúa con las páginas web, no está orientado a conexión, ya que por sí mismo no proporciona manera de almacenar las acciones que el navegante realiza en una página web, ¿cómo es posible mantener una sesión web?
Para mantener las sesiones web el navegador y el servidor web comparten un identificador único que el navegador web incluye en cada petición HTTP o HTTPS realizada al portal (generalmente mediante cookies). De este modo, por medio de este identificador, el servidor web puede reconocer que la petición que recibe pertenece a una determinada sesión, almacenar la información de esta petición que le interese y responder a ella según la información almacenada anteriormente.
Normalmente, al autenticarse un usuario en una página web o portal, se incluye en la información de sesión el identificador del usuario; de este modo, en peticiones HTTP posteriores el portal reconoce, a través del identificador de sesión, a qué usuario corresponde esa petición y puede asociarle las acciones realizadas y personalizar su contenido. Del mismo modo, al salir un usuario de un portal o aplicación web, éste cierra la sesión web.
En la siguiente imagen se pude apreciar un diálogo entre el navegador y el servidor web capturado con el complemento de Firefox Live HTTP headers, también se puede utilizar ieHTTPHeaders para Internet Explorer:
La imagen muestra como, en un primer momento, el servidor envía una cabecera en la que solicita que el cliente almacene una cookie que contiene el identificador de sesión y, posteriormente, el navegador incluye esta cookie en la respuesta para que el servidor reconozca que la petición pertenece a una determinada sesión.
Otra ventaja del uso de los identificadores de sesión es que permiten que la información asociada a la sesión esté almacenada en el servidor, un entorno de seguridad más controlado, al que no tiene acceso el cliente directamente.
Mediante el identificador de sesión el servidor discierne la sesión a la que pertenece la petición HTTP. Por tanto, si un atacante obtiene o genera un identificador de sesión válido y realiza peticiones web en las que incluye este identificador, podrá suplantar al usuario en su sesión web y realizar acciones en su nombre sin su consentimiento. En la práctica el resultado del ataque es similar a que el atacante conociera el nombre de usuario y la contraseña del usuario afectado.
Este tipo de ataques son muy graves y comunes, de hecho, junto con la gestión de autenticación y todos tienen un mismo objetivo, obtener identificadores de sesión válidos para suplantar al usuario, se diferencian en el modo de hacerlo.
Este tipo de ataque se centra en generar un identificador válido. Para ello, el atacante aprovecha los patrones de generación de identificadores de sesión que pueda utilizar el servidor y, una vez reducido el espacio de búsqueda, prueba todas las posibilidades posibles mediante fuerza bruta.
Aleatorización y longitud suficiente del identificador de sesión como ejemplo, PHP utiliza como identificador un hash de 16 o 20 bytes creado a partir de una cadena de texto que se compone de:
La dirección remota del cliente HTTP.
Información del tiempo de ejecución.
Datos aleatorios.
Opcionalmente, dependiendo de la opción session.entropy_length, permite añadir a la fuente del hash datos aleatorios obtenidos a partir del API de Windows o del archivo /dev/random en sistemas Unix.
Si una página web presenta una vulnerabilidad XSS un atacante puede aprovecharla para ejecutar código que capture el contenido de la cookie y se lo envíe. Para evitarlo se creó la etiqueta httponly, de modo que el navegador impide el acceso por medio de scripts a las cookies que tienen este atributo, aunque existen maneras de capturar el valor de la cookie aunque sea httponly a través del método TRACE.
Activar la opción httponly en el servidor web.
Deshabilitar el método TRACE.
Este tipo de ataque sigue un camino distinto del resto, en vez de capturar un identificador de sesión valido, genera un identificador genuino (que no está asociado a ningún usuario por el momento) en el portal web afectado para, a continuación, tratar de que la víctima se autentique en el portal con él. De este modo, el atacante obtiene un identificador de un usuario autenticado que puede utilizar para realizar acciones en el portal afectado en nombre de la víctima.
En el siguiente diagrama se observa el proceso del ataque:
1 y 2: el atacante realiza una petición HTTP al servidor con el único objetivo de obtener un identificador de sesión.
3: el atacante elabora una petición HTTP que incluye el identificador de sesión y se lo hace llegar a la víctima, más adelante se describirá de qué manera, como puede ser la siguiente: En este punto se produce la primera vulnerabilidad que posibilita los ataques de fijación de sesión, el atacante puede crear una petición al sitio web vulnerable que permite incluir el identificador de sesión.
4 y 5: la víctima realiza la petición HTTP que le indicó el atacante e inicia sesión en el portal con el identificador de sesión que conoce el atacante. Este es el segundo error que permite realizar este tipo de ataques: después de la autenticación el identificador de sesión es el mismo que antes.
6: En este punto, el atacante dispone de un identificador de sesión asociado a la víctima con el que puede suplantarla en el portal web vulnerable.
Una variación de este ataque, publicado en el blog Security Art Work, utiliza técnicas man-in-the-middle y consiste en que, previamente a los pasos 1 y 2, el atacante hace llegar a la víctima un enlace malicioso que supuestamente apunta al portal web pero que en realidad lo hace a un servidor controlado por el atacante. Si la víctima sigue el enlace, el servidor malicioso realiza los pasos 1 y 2 como en el caso anterior y, en el tercer paso, redirige la petición original de la víctima al servidor web vulnerable junto con el identificador de sesión obtenido. Esta variación tiene la ventaja de que no transcurre un lapso de tiempo entre la generación del identificador por parte del atacante y la autenticación de sesión por parte de la víctima.
En el paso 3 se ha citado que el atacante ha de ser capaz de construir una petición HTTP que incluya el identificador de sesión. Esto es sencillo de conseguir si el portal web vulnerable permite que el identificador se reciba en un parámetro GET, POST o en un campo oculto. Pero, no lo es tanto si únicamente permite que se transmita en una cookie, ya que por las políticas del «mismo origen» que implementan todos los navegadores, no se pueden modificar los objetos de otros dominios. Aún así, existen formas de modificar las cookies como las siguientes, obtenidas de la presentación «SAP: Session (Fixation) Attacks and Protections» de la Black Hat Europe 2011, aunque o los navegadores ya las previenen o posibilitan formas más sencillas de obtener el identificador de sesión:
Incluir la cookie en una etiqueta HTTP meta:
Manipular la petición web para incluir la cookie de atacante. Aunque si esto es posible, se puede capturar directamente el identificador y no es necesario el ataque de fijación de sesión.
Mediante ataques XSS. Aunque, como el caso anterior, posibilita la captura del identificador.
Explotando una vulnerabilidad de HTTP response splitting:
Inyectar el identificador de sesión como parámetro GET y puede que aunque el portal web espere el identificador en una cookie también procese el identificador si viene en un parámetro GET.
Renovar el identificador al autenticarse el usuario o asignarlo únicamente después de la autenticación.
Permitir únicamente el identificador en cookies.
Asociar el identificador a información del usuario única como su dirección IP.
Hasta aquí la primera parte, pronto la segunda parte.
Si HTTP, el protocolo con el que se interactúa con las páginas web, no está orientado a conexión, ya que por sí mismo no proporciona manera de almacenar las acciones que el navegante realiza en una página web, ¿cómo es posible mantener una sesión web?
Para mantener las sesiones web el navegador y el servidor web comparten un identificador único que el navegador web incluye en cada petición HTTP o HTTPS realizada al portal (generalmente mediante cookies). De este modo, por medio de este identificador, el servidor web puede reconocer que la petición que recibe pertenece a una determinada sesión, almacenar la información de esta petición que le interese y responder a ella según la información almacenada anteriormente.
Normalmente, al autenticarse un usuario en una página web o portal, se incluye en la información de sesión el identificador del usuario; de este modo, en peticiones HTTP posteriores el portal reconoce, a través del identificador de sesión, a qué usuario corresponde esa petición y puede asociarle las acciones realizadas y personalizar su contenido. Del mismo modo, al salir un usuario de un portal o aplicación web, éste cierra la sesión web.
En la siguiente imagen se pude apreciar un diálogo entre el navegador y el servidor web capturado con el complemento de Firefox Live HTTP headers, también se puede utilizar ieHTTPHeaders para Internet Explorer:
La imagen muestra como, en un primer momento, el servidor envía una cabecera en la que solicita que el cliente almacene una cookie que contiene el identificador de sesión y, posteriormente, el navegador incluye esta cookie en la respuesta para que el servidor reconozca que la petición pertenece a una determinada sesión.
Otra ventaja del uso de los identificadores de sesión es que permiten que la información asociada a la sesión esté almacenada en el servidor, un entorno de seguridad más controlado, al que no tiene acceso el cliente directamente.
Ataques y medidas de seguridad
Mediante el identificador de sesión el servidor discierne la sesión a la que pertenece la petición HTTP. Por tanto, si un atacante obtiene o genera un identificador de sesión válido y realiza peticiones web en las que incluye este identificador, podrá suplantar al usuario en su sesión web y realizar acciones en su nombre sin su consentimiento. En la práctica el resultado del ataque es similar a que el atacante conociera el nombre de usuario y la contraseña del usuario afectado.
Este tipo de ataques son muy graves y comunes, de hecho, junto con la gestión de autenticación y todos tienen un mismo objetivo, obtener identificadores de sesión válidos para suplantar al usuario, se diferencian en el modo de hacerlo.
Predicción de Sesión
Este tipo de ataque se centra en generar un identificador válido. Para ello, el atacante aprovecha los patrones de generación de identificadores de sesión que pueda utilizar el servidor y, una vez reducido el espacio de búsqueda, prueba todas las posibilidades posibles mediante fuerza bruta.
Solución
Aleatorización y longitud suficiente del identificador de sesión como ejemplo, PHP utiliza como identificador un hash de 16 o 20 bytes creado a partir de una cadena de texto que se compone de:
Muestra de código PHP para el identificador:
Capturar el Identificador con Ataques XSS
Si una página web presenta una vulnerabilidad XSS un atacante puede aprovecharla para ejecutar código que capture el contenido de la cookie y se lo envíe. Para evitarlo se creó la etiqueta httponly, de modo que el navegador impide el acceso por medio de scripts a las cookies que tienen este atributo, aunque existen maneras de capturar el valor de la cookie aunque sea httponly a través del método TRACE.
Solución
Fijación se Sesión
Este tipo de ataque sigue un camino distinto del resto, en vez de capturar un identificador de sesión valido, genera un identificador genuino (que no está asociado a ningún usuario por el momento) en el portal web afectado para, a continuación, tratar de que la víctima se autentique en el portal con él. De este modo, el atacante obtiene un identificador de un usuario autenticado que puede utilizar para realizar acciones en el portal afectado en nombre de la víctima.
En el siguiente diagrama se observa el proceso del ataque:
1 y 2: el atacante realiza una petición HTTP al servidor con el único objetivo de obtener un identificador de sesión.
3: el atacante elabora una petición HTTP que incluye el identificador de sesión y se lo hace llegar a la víctima, más adelante se describirá de qué manera, como puede ser la siguiente: En este punto se produce la primera vulnerabilidad que posibilita los ataques de fijación de sesión, el atacante puede crear una petición al sitio web vulnerable que permite incluir el identificador de sesión.
4 y 5: la víctima realiza la petición HTTP que le indicó el atacante e inicia sesión en el portal con el identificador de sesión que conoce el atacante. Este es el segundo error que permite realizar este tipo de ataques: después de la autenticación el identificador de sesión es el mismo que antes.
6: En este punto, el atacante dispone de un identificador de sesión asociado a la víctima con el que puede suplantarla en el portal web vulnerable.
Una variación de este ataque, publicado en el blog Security Art Work, utiliza técnicas man-in-the-middle y consiste en que, previamente a los pasos 1 y 2, el atacante hace llegar a la víctima un enlace malicioso que supuestamente apunta al portal web pero que en realidad lo hace a un servidor controlado por el atacante. Si la víctima sigue el enlace, el servidor malicioso realiza los pasos 1 y 2 como en el caso anterior y, en el tercer paso, redirige la petición original de la víctima al servidor web vulnerable junto con el identificador de sesión obtenido. Esta variación tiene la ventaja de que no transcurre un lapso de tiempo entre la generación del identificador por parte del atacante y la autenticación de sesión por parte de la víctima.
En el paso 3 se ha citado que el atacante ha de ser capaz de construir una petición HTTP que incluya el identificador de sesión. Esto es sencillo de conseguir si el portal web vulnerable permite que el identificador se reciba en un parámetro GET, POST o en un campo oculto. Pero, no lo es tanto si únicamente permite que se transmita en una cookie, ya que por las políticas del «mismo origen» que implementan todos los navegadores, no se pueden modificar los objetos de otros dominios. Aún así, existen formas de modificar las cookies como las siguientes, obtenidas de la presentación «SAP: Session (Fixation) Attacks and Protections» de la Black Hat Europe 2011, aunque o los navegadores ya las previenen o posibilitan formas más sencillas de obtener el identificador de sesión:
Solución
Hasta aquí la primera parte, pronto la segunda parte.
