Ola, somos Arume

Desenvolvemos páxinas web, aplicacións para móbiles, capas de realidade aumentada e aplicacións para Facebook. Apaixónanos a informática e somos uns perfeccionistas incurables; por eso nos nosos proxectos utilizamos estándares.

tel. 625 519 694

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

Autenticarse

Rexistrarse. Esqueceches o teu contrasinal?

Etiquetas

Saltar as etiquetas

Subscríbete ás RSS

Estás en:

  • Inicio >
  • Blog >
  • Seguridade das sesións en PHP: Session Hijacking

Seguridade das sesións en PHP: Session Hijacking

13 Dec 2010 por Luis

Comentarios: 12

Roubo de indentidade

Session Hijacking (secuestro ou roubo de sesión) refírese a que un individuo (atacante) consegue o identificador de sesión entre unha páxina web e un usuario, de forma que pode facerse pasar por este e acceder á súa conta nesa páxina web.

O roubo da sesión pode conseguirse de varias formas, aínda que neste artigo centrarémonos nas que teñen que ver cas vulnerabilidades das sesións e nalgunhas técnicas para mitigalas.

Como puidemos ver no artigo sobre o funcionamento das sesións, a única forma que ten a páxina web de recoñecer a un usuario é por medio do seu identificador de sesión. Se un atacante consegue o identificador de sesión dun usuario que xa está autenticado, pode facerse pasar por el e entrar na súa conta só con facer que o seu navegador envíe o identificador á páxina web, xa sexa a través da URL ou dunha cookie.

A continuación veremos algunhas das formas nas que un atacante pode roubar este identificador e técnicas para intentar previlo.

Ataque por forza bruta

O ataque por forza bruta significa probar identificadores aleatoriamente ata atopar un que estea sendo usado. É como intentar abrir unha caixa forte sen saber a combinación, pondo números ó azar.

Como no caso da caixa forte, cantos máis números teña a combinación (neste caso o identificador de sesión), máis difícil será de adiviñar. Tamén axuda o feito de que o número ou identificador sexa aleatorio, e non algo que se poida predicir. O sistema de identificadores de sesión de PHP é aceptable neste sentido.

Roubo por sniffing

Este tipo de ataque dáse cando o atacante ten un programa de sniffing na rede do usuario e pode interceptar o tráfico destinado ao mesmo, incluído o seu identificador de sesión. É algo que deu moito de que falar por mor de Firesheep, unha extensión para Firefox que permite roubar as sesións de Facebook, Twitter e outras páxinas web moi coñecidas en redes inalámbricas públicas.

A única forma de previr estes ataques é utilizando cifrado HTTPS en toda a páxina web.

Propagación en URL

Se o identificador de sesión se propaga utilizando a URL en lugar das cookies, calquera atacante pode roubalo desde moitos sitios:

  • Unha ligazón que o propio usuario poña nun lugar público. Os usuarios típicos non saben para que serve ese identificador e non lle dan importancia.
  • O historial do navegador.
  • O referrer, que é un encabezado que envían moitos navegadores ás páxinas web no que lles indican a URL da que veñen.

A forma de previr isto é non utilizar a URL para o identificador de sesión; utilizar unicamente as cookies. En PHP isto conséguese coa instrución:

ini_set('session.use_only_cookies', 1);

Roubo en servidor compartido

Se temos a nosa páxina web aloxada nun servidor compartido, os arquivos físicos das sesións gárdanse, por defecto, nun directorio común para todas as páxinas web do servidor. Isto quere dicir que todas as persoas que teñan a súa páxina web nese mesmo servidor, teñen acceso a todos os arquivos de sesións. Dado que o nome dos arquivos é "sess_" máis o identificador de sesión, calquera atacante terá unha lista de identificadores de sesión válidos con só ler a lista de arquivos do directorio común.

Esta vulnerabilidade pódese combater de dúas formas:

  • Usando a función session_save_path para gardar os arquivos de sesión da páxina web nun directorio dentro da súa conta ao que só poida acceder PHP (xa sexa por estar fóra do directorio web ou cun .htaccess ca instrución deny from all). Este método non é demasiado fiable, xa que o resto de usuarios seguirá podendo ler nese directorio, só teñen que pescudar a súa localización.
  • Gardando as sesións en base de datos en lugar de en arquivos. Isto conséguese facilmente usando a función session_set_save_handler. Esta solución é a máis segura xa que a páxina web será a única que terá acceso á base de datos e, xa que logo, ás sesións.

Roubo por Cross-Site Scripting

Se a páxina web é vulnerable a XSS o atacante pode inserir un código javascript que envíe as cookies dun usuario á súa conta.

Este tipo de ataque pódese previr (ademais de evitando os ataques XSS) facendo que as cookies de sesión teñan o atributo HttpOnly, que evita que poidan ser manexadas por javascript na maioría de navegadores. En PHP isto conséguese coa instrución:

ini_set('session.cookie_httponly', 1);

Métodos de prevención xerais

Ademais dos métodos de prevención concretos vistos para cada tipo de ataque, imos ver algunhas técnicas de prevención que axudan a evitar o roubo das sesións:

  • Limitar tempo de inactividade: eliminar a sesión se está certo tempo sen ser usada (de 5 a 30 minutos, segundo o nivel de seguridade da páxina web).
  • Cambiar o identificador de sesión: cada certo tempo ou logo de cada acción, cambiar o identificador da sesión por outro distinto e eliminar a sesión antiga.
  • Sistema de logout: dar ós usuarios unha forma de saír da súa conta e destruír a sesión.
  • Verificación dobre: usar un segundo método para intentar recoñecer ó usuario da sesión. Isto pode facerse gardando cabeceiras como HTTP_USER_AGENT (navegador do usuario) ou REMOTE_ADDR (IP do usuario) cando se crea a sesión, desta forma:

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

    A IP do usuario é máis significativa que o seu navegador, pero é máis problemática xa que hai usuarios aos que lles cambia a IP habitualmente (IP dinámica, proxies, ...).

    Con este sistema, un atacante tería que roubar a sesión a un usuario e, ademais, enviar a mesma cabeceira de navegador para poder usala.

Ata aquí o artigo sobre o roubo de sesións. En próximos artigos veremos máis tipos de ataque contra as sesións e formas de previlos.

Comentarios

12 comentarios. Comentar.

1. Yhoni o 23 Xan 2012 ás 20:35:49

Muy util, gracias.

2. Anónimo o 10 Mai 2012 ás 17:54:56

muy bueno !!

3. Anónimo o 16 Mai 2012 ás 03:10:54

Super. De muchisima utilidad. Muchas gracias.

4. Anónimo o 08 Xul 2012 ás 05:18:02

buenisimo!

5. Anónimo o 02 Ago 2012 ás 18:34:51

exelente, me gustan tus post.

aparte de ser bien explicados!

6. Mesk o 10 Dec 2012 ás 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 o 13 Dec 2012 ás 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 o 12 Nov 2015 ás 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 o 12 Nov 2015 ás 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 o 08 Dec 2015 ás 00:14:04

Excelente aportación, saludos.

11. Rodrigo Silva o 25 Out 2016 ás 16:50:05

Excelente articulo, muy util!

12. Anónimo o 21 Xul 2017 ás 02:15:50

te amo

Comentar

Comentar de forma anónima

Podes comentar poñendo calquera nome ou alcume, exceptuando os nomes de usuarios rexistrados. Máximo de 50 caracteres.

Comentar como usuario rexistrado

Rexistrarse. Esqueceches o teu contrasinal?