Hola, somos Arume

Desarrollamos páginas web, aplicaciones para móviles, capas de realidad aumentada y aplicaciones para Facebook. Nos apasiona la informática y somos unos perfeccionistas incurables; por eso en nuestros proyectos utilizamos estándares.

tel. 625 519 694

Mendaña de Neyra, 34, 3º B, 15008, A Coruña

Autenticarse

Registrarse. ¿Has olvidado tu contraseña?

Etiquetas

Saltar las etiquetas

Suscríbete a las RSS

Estás en:

  • Inicio >
  • Blog >
  • Seguridad de las sesiones en PHP: Session Hijacking

Seguridad de las sesiones en PHP: Session Hijacking

13 Dic 2010 por Luis

Comentarios: 12

Robo de indentidad

Session Hijacking (secuestro o robo de sesión) se refiere a que un individuo (atacante) consigue el identificador de sesión entre una página web y un usuario, de forma que puede hacerse pasar por este y acceder a su cuenta en esa página web.

El robo de la sesión puede conseguirse de varias formas, aunque en este artículo nos centraremos en las que tienen que ver con las vulnerabilidades de las sesiones y en algunas técnicas para mitigarlas.

Como pudimos ver en el artículo sobre el funcionamiento de las sesiones, la única forma que tiene la página web de reconocer a un usuario es por medio de su identificador de sesión. Si un atacante consigue el identificador de sesión de un usuario que ya está autenticado, puede hacerse pasar por él y entrar en su cuenta sólo con hacer que su navegador envíe el identificador a la página web, ya sea a través de la URL o de una cookie.

A continuación veremos algunas de las formas en las que un atacante puede robar este identificador y técnicas para intentar prevenirlo.

Ataque por fuerza bruta

El ataque por fuerza bruta significa probar identificadores aleatoriamente hasta encontrar uno que esté siendo usado. Es como intentar abrir una caja fuerte sin saber la combinación, poniendo números al azar.

Como en el caso de la caja fuerte, cuantos más números tenga la combinación (en este caso el identificador de sesión), más difícil será de adivinar. También ayuda el hecho de que el número o identificador sea aleatorio, y no algo que se pueda predecir. El sistema de identificadores de sesión de PHP es aceptable en este sentido.

Robo por sniffing

Este tipo de ataque se da cuando el atacante tiene un programa de sniffing en la red del usuario y puede interceptar el tráfico destinado al mismo, incluido su identificador de sesión. Es algo que ha dado mucho de que hablar a causa de Firesheep, una extensión para Firefox que permite robar las sesiones de Facebook, Twitter y otras páginas web muy conocidas en redes inalámbricas públicas.

La única forma de prevenir estos ataques es utilizando cifrado HTTPS en toda la página web.

Propagación en URL

Si el identificador de sesión se propaga utilizando la URL en lugar de las cookies, cualquier atacante puede robarlo desde muchos sitios:

  • Un enlace que el propio usuario ponga en un lugar público. Los usuarios típicos no saben para que sirve ese identificador y no le dan importancia.
  • El historial del navegador.
  • El referrer, que es un encabezado que envían muchos navegadores a las páginas web en el que les indican la URL de la que vienen.

La forma de prevenir esto es no utilizar la URL para el identificador de sesión; utilizar únicamente las cookies. En PHP esto se consigue con la instrucción:

ini_set('session.use_only_cookies', 1);

Robo en servidor compartido

Si tenemos nuestra página web alojada en un servidor compartido, los archivos físicos de las sesiones se guardan, por defecto, en un directorio común para todas las páginas web del servidor. Esto quiere decir que todas las personas que tengan su página web en ese mismo servidor, tienen acceso a todos los archivos de sesiones. Dado que el nombre de los archivos es "sess_" más el identificador de sesión, cualquier atacante tendrá una lista de identificadores de sesión válidos con sólo leer la lista de archivos del directorio común.

Esta vulnerabilidad se puede combatir de dos formas:

  • Usando la función session_save_path para guardar los archivos de sesión de la página web en un directorio dentro de su cuenta al que sólo pueda acceder PHP (ya sea por estar fuera del directorio web o con un .htaccess con la instrucción deny from all). Este método no es demasiado fiable, ya que el resto de usuarios seguirá pudiendo leer en ese directorio, sólo tienen que averiguar su localización.
  • Guardando las sesiones en base de datos en lugar de en archivos. Esto se consigue fácilmente usando la función session_set_save_handler. Esta solución es la más segura ya que la página web será la única que tendrá acceso a la base de datos y, por tanto, a las sesiones.

Robo por Cross-Site Scripting

Si la página web es vulnerable a XSS el atacante puede insertar un código javascript que envíe las cookies de un usuario a su cuenta.

Este tipo de ataque se puede prevenir (además de evitando los ataques XSS) haciendo que las cookies de sesión tengan el atributo HttpOnly, que evita que puedan ser manejadas por javascript en la mayoría de navegadores. En PHP esto se consigue con la instrucción:

ini_set('session.cookie_httponly', 1);

Métodos de prevención generales

Además de los métodos de prevención concretos vistos para cada tipo de ataque, vamos a ver algunas técnicas de prevención que ayudan a evitar el robo de las sesiones:

  • Limitar tiempo de inactividad: eliminar la sesión si está cierto tiempo sin ser usada (de 5 a 30 minutos, según el nivel de seguridad de la página web).
  • Cambiar el identificador de sesión: cada cierto tiempo o después de cada acción, cambiar el identificador de la sesión por otro distinto y eliminar la sesión antigua.
  • Sistema de logout: dar a los usuarios una forma de salir de su cuenta y destruir la sesión.
  • Verificación doble: usar un segundo método para intentar reconocer al usuario de la sesión. Esto puede hacerse guardando cabeceras como HTTP_USER_AGENT (navegador del usuario) o REMOTE_ADDR (IP del usuario) cuando se crea la sesión, de esta forma:

    $_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT']);

    La IP del usuario es más significativa que su navegador, pero es más problemática ya que hay usuarios a los que les cambia la IP habitualmente (IP dinámica, proxies, ...).

    Con este sistema, un atacante tendría que robar la sesión a un usuario y, además, enviar la misma cabecera de navegador para poder usarla.

Hasta aquí el artículo sobre el robo de sesiones. En próximos artículos veremos más tipos de ataque contra las sesiones y formas de prevenirlos.

Comentarios

12 comentarios. Comentar.

1. Yhoni el 23 Ene 2012 a las 20:35:49

Muy util, gracias.

2. Anónimo el 10 May 2012 a las 17:54:56

muy bueno !!

3. Anónimo el 16 May 2012 a las 03:10:54

Super. De muchisima utilidad. Muchas gracias.

4. Anónimo el 08 Jul 2012 a las 05:18:02

buenisimo!

5. Anónimo el 02 Ago 2012 a las 18:34:51

exelente, me gustan tus post.

aparte de ser bien explicados!

6. Mesk el 10 Dic 2012 a las 20:39:02

no esta de mas hablar del ataque DDOS y la importancia de la encriptacion de ciertos datos criticos y el uno de un SSL. Pero muy buen articulo

7. Luis el 13 Dic 2012 a las 10:54:53

Gracias por participar, Mesk.

Este artículo es sobre Session Hijacking, y los ataques DDOS no tienen que ver para nada con este tema (ni siquiera es un tipo de ataque contra las sesiones). Lo mismo pasa con la encriptación de datos, que no tiene nada que ver con el robo de sesiones (sobre esa cuetión tienes un artículo en esta URL http://www.arumeinformatica.es/blog/encriptar-y-guardar-c...).

Por último, el uso de SSL se recomienda como solución al apartado "Robo por sniffing".

Un saludo.

8. Rafael Contreras el 12 Nov 2015 a las 18:11:24

Hola que tal, estoy teniendo un problema con las sesiones, te comento que mis sesiones se están cruzando, pero solo ocurre cuando tengo más de 15 usuarios en simultáneo, quizás conoces a alguien que le pase lo mismo, y puedas darme unas pistas de porque sucede. Gracias. La aplicación está en Zend Framework 2.

9. Rafael Contreras el 12 Nov 2015 a las 18:11:25

Hola que tal, estoy teniendo un problema con las sesiones, te comento que mis sesiones se están cruzando, pero solo ocurre cuando tengo más de 15 usuarios en simultáneo, quizás conoces a alguien que le pase lo mismo, y puedas darme unas pistas de porque sucede. Gracias. La aplicación está en Zend Framework 2.

10. Salvador Romero el 08 Dic 2015 a las 00:14:04

Excelente aportación, saludos.

11. Rodrigo Silva el 25 Oct 2016 a las 16:50:05

Excelente articulo, muy util!

12. Anónimo el 21 Jul 2017 a las 02:15:50

te amo

Comentar

Comentar de forma anónima

Puedes comentar poniendo cualquier nombre o apodo, exceptuando los nombres de usuarios registrados. Máximo de 50 caracteres.

Comentar como usuario registrado

Registrarse. ¿Has olvidado tu contraseña?