Jump to content
Santana Oliveira

[Resolvido] Prevenir roubo de Sessões PHP

Recommended Posts

Santana Oliveira

Ola

Como posso prevenir o roubo das sessões em PHP?

Ou seja aquele roubo que se faz com os ids das sessões.

Alguém me pode Ajudar?

Obrigado

Share this post


Link to post
Share on other sites
bioshock

Este tópico acaba de me interessar, porque o meu conhecimento referente ao roubo de sessões é quase nulo. Já ouvi falar, mas nunca me despertou grande atenção visto ficarem do lado do servidor.

Num sistema de login, que é o exemplo mais prático e comum, no cookie guardo o email. Nas sessões guardo o email e o id. Não faço qualquer tipo de encriptação, simplesmente depois comparo se o valor do cookie é igual ao valor da sessão, neste caso o email.

Olhando agora para a pergunta do tópico, de que forma posso eu ser prejudicado? Será benéfico encriptar tanto os valores do cookie como das sessões?

Share this post


Link to post
Share on other sites
fil79

Guardar o user_agent, e comparar se quem está a fazer o pedido para determinado Id tem de ser feito pelo mesmo browser.

<?php
session_start();
if (isset($_SESSION['HTTP_USER_AGENT']))
{
if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT']))
{
/* Prompt for password */
exit;
}
}
else
{
$_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);
}
?>


MCITP-MCTS-MCP

Share this post


Link to post
Share on other sites
scorch

@bioshock Isso é extremamente inseguro. Eu posso saber qual é o teu email, vou ver o teu ID (em muitas plataformas isso não é muito dífici, as páginas de utilizador e afins mostram o ID nem que seja na barra de endereços). Ou seja, a mim basta-me criar um cookie com o email e o ID e tenho a sessão que quiser, até de um administrador.

Eu não tenho a certeza de como o PHP trabalha internamente com as sessões, mas por alto suponho que cada vez que alguém inicie uma sessão, o PHP gere un token grandezito e completamente aleatório e o passe ao cliente para guardar num cookie, e depois disso guarda no servidor, numa localização temporária e inacessível, provavelmente em ficheiros, guarda a associação desse token com os dados da variável $_SESSION.

Assim sendo, para ocorrer roubo de sessão, alguém tem de saber qual é a string única que está naquele cookie em específico (e que dependendo do tamanho da mesma, pode ser impossível de adivinhar com brute-force). É óbvio que existem sempre algumas técnicas para diminuir as chances de roubo de sessão acontecer. Uma delas é verificar o IP, mas isto também quer dizer que a sessão é invalidada se o meu router se lembrar de mudar de IP enquanto eu navego num site. Também se pode pedir a palavra-passe de vez em quando e gerar um novo token, assim mesmo que alguém consiga roubar a sessão tem um tempo limitado, ou até pedir a palavra passe para acções mais sensíveis, como editar o perfil ou as definições.

Por fim, ativar SSL é uma grande ajuda, pois encriptando as comunicações entre o servidor e o cliente, faz com que o cookie não possa ser roubado externamente, ou seja, o "ladrão" necessita de ter acesso direto ao computador (seja com vírus ou mesmo acesso físico) para roubar o cookie. ;)

Edited by scorch

PS: Não respondo a perguntas por mensagem que podem ser respondidas no fórum.

Share this post


Link to post
Share on other sites
Knitter

Não há forma nenhuma de prevenir roubo de sessões por cookie.

Dito isto, tudo o que podes fazer é complicar o roubo, e nesse ponto há alguns elementos base que podes usar:

  • Usar HTTPS, previne que o tráfego possa ser interceptado
  • Impedir o acesso por JS ao cookie definindo apenas acesso HTTP
  • Garantir que o cookie tem prazo de validade
  • Como extra podes usar dados sobre o browser para tentar dificultar um pouco mais, mas esses são demasiados simples de forjar, ex.: user agent ou IP

Share this post


Link to post
Share on other sites
bioshock

@bioshock Isso é extremamente inseguro. Eu posso saber qual é o teu email, vou ver o teu ID (em muitas plataformas isso não é muito dífici, as páginas de utilizador e afins mostram o ID nem que seja na barra de endereços). Ou seja, a mim basta-me criar um cookie com o email e o ID e tenho a sessão que quiser, até de um administrador.

Não percebi o porquê de teres dito que crias um cookie com email....e ID. Sublinho o ID pois eu não guardo em Cookie o ID, apenas o email que por norma conta com uma validade máxima de 7 dias.

O ID só é guardado em sessão, nunca em cookie. Um exemplo prático:

if(isset($_COOKIE['email']) && isset($_SESSION['email'])){
   if($_SESSION['email'] == $_COOKIE['email']){
     // Faz o que tem a fazer
   }
}

Como é que alguém consegue alterar uma sessão, que fica do lado do servidor, neste caso do valor email, para fazer qualquer tipo de malabarismos?

Share this post


Link to post
Share on other sites
yoda

Como é que alguém consegue alterar uma sessão, que fica do lado do servidor, neste caso do valor email, para fazer qualquer tipo de malabarismos?

Não é no servidor que mexem, é no cookie .. com javascript injectado num site a direccionar para um servidor PHP consegues apanhar o cookie de um cliente que esteja logado (logo a sessão é válida) e fazer o que quiseres a partir daí. É estupidamente simples.

Share this post


Link to post
Share on other sites
scorch

Exacto. Para além disso, o que eu estava a dizer é que um cookie com o email (tenha ou não o ID) não acrescenta nenhuma segurança, pois o email é algo público e quase imutável, logo é extremamente fácil quem conseguir "roubar" o cookie da sessão, criar um cookie com o email. Não é nenhum impeditivo. :)


PS: Não respondo a perguntas por mensagem que podem ser respondidas no fórum.

Share this post


Link to post
Share on other sites
bioshock

Se é assim tão simples, porque não dizer que, sei lá, uma grande percentagem dos sites, têm essa falha e ninguém explora?

Usar HTTPS, previne que o tráfego possa ser interceptado

Esta opção já sabia, mas apesar de nunca ter implementado, tenho sempre a impressão que é uma feature cara.

Impedir o acesso por JS ao cookie definindo apenas acesso HTTP

Como?

Share this post


Link to post
Share on other sites
scorch

E para além do que o yoda disse, convém especificar que se o site usar SSL, impedindo o tráfego de ser escutado por terceiros, para roubar o cookie passa a ser necessário, como já disse, acesso direto ao computador. Uma vez que roubar um cookie pouco mais dificil é que roubar um ficheiro, um simples vírus serve.

Ou seja, a proteção passa a estar da responsabilidade dos utilizadores também, isto não é propriamente uma vulnerabilidade do site, apesar de o mesmo poder aumentar a segurança para minimizar os riscos, mas sim dos computadores das pessoas, e por isso se não querem ser alvo de roubo de sessões, os utilizadores é que devem ter os cuidados do costume: antivírus, ter cuidado com o que se abre, verificar os anexos dos e-mails, etc... :)


PS: Não respondo a perguntas por mensagem que podem ser respondidas no fórum.

Share this post


Link to post
Share on other sites
bioshock

Eu continuo um bocado céptico, mas não deixo de ter em conta o que disseram.

Se dizem que é assim tão simples, podem ensinar ou há algum tutorial que ensine a fazer isso? Tenho interesse, pois podia ver até que ponto os sites que tenho desenvolvido até ao momento são ou não seguros nesse aspecto. Nenhum deles tem qualquer tipo de https ou ssl a trabalhar por trás.

Share this post


Link to post
Share on other sites
yyajsayy

Basta num dos sistemas que desenvolveste teres esquecido a verificação dos inputs do utilizador e "capute". Por norma, e é frequente, os formulários de registo de account serem os mais sofredores com tipos de ataque Cross site scripting (XSS). Não me quero alongar, isto apenas, para dizer que num simples campo de "Nome de utilizador" é possível a injeção de código malicioso posteriormente gravado na base de dados, que poderá danificar o sistema, falo por exemplo em desfiguração, ou até roubo de dados de autenticação dos utilizadores!

À primeira vista o XSS parece inofensivo mas é uma besta :P

Boa continuação!

Edited by yyajsayy

"If it don't work the first time, rename it to version 1.0."

http://seguranca-informatica.pt

Share this post


Link to post
Share on other sites
I-NOZex

e quem fala em XSS, fala em sql inject tambem

nada na web é seguro, o que nos resta é dificultar usando tudo que esteja ao nosso dispor

  • Vote 1

B2R » Beat2Revolution v3.0b | Regista e divulga-nos

beat2revolution.net

Share this post


Link to post
Share on other sites
bioshock

Basta num dos sistemas que desenvolveste teres esquecido a verificação dos inputs do utilizador e "capute". Por norma, e é frequente, os formulários de registo de account serem os mais sofredores com tipos de ataque Cross site scripting (XSS). Não me quero alongar, isto apenas, para dizer que num simples campo de "Nome de utilizador" é possível a injeção de código malicioso posteriormente gravado na base de dados, que poderá danificar o sistema, falo por exemplo em desfiguração, ou até roubo de dados de autenticação dos utilizadores!

À primeira vista o XSS parece inofensivo mas é uma besta :P

Boa continuação!

e quem fala em XSS, fala em sql inject tambem

nada na web é seguro, o que nos resta é dificultar usando tudo que esteja ao nosso dispor

Utilizo em todos os sistemas a extensão mysqli e não a tradicional. Pelo que, até à data, com parâmetros, estás totalmente precavido desses ataques.

  • Vote 1

Share this post


Link to post
Share on other sites
I-NOZex

como podes imaginar isso nao é suficiente, mas decerto acredito que faças sempre validaçao de cliente e servidor...


B2R » Beat2Revolution v3.0b | Regista e divulga-nos

beat2revolution.net

Share this post


Link to post
Share on other sites
bioshock

como podes imaginar isso nao é suficiente, mas decerto acredito que faças sempre validaçao de cliente e servidor...

Na verdade é suficiente, mais, é a única solução onde os 100% aplicam-se, pelo menos no que toca ao SQLinjection.

Mas o que me trouxe ao tópico não foi isto, continuo sem saber então como fazer essa manipulação dos dados..visto que é assim tão fácil, deve ser possível alguém me dizer como (?).

Share this post


Link to post
Share on other sites
Knitter

Mas o que me trouxe ao tópico não foi isto, continuo sem saber então como fazer essa manipulação dos dados..visto que é assim tão fácil, deve ser possível alguém me dizer como (?).

Sim, "alguém" podia dizer-te como, ou tu podias aproveitar a oportunidade para estudar um pouco mais sobre o assunto :) . Não há nada como começar (e começar é a palavra chave) pela Wikipédia: http://en.wikipedia.org/wiki/HTTP_cookie, http://en.wikipedia.org/wiki/Session_hijacking , http://en.wikipedia.org/wiki/Cross-site_scripting, http://en.wikipedia.org/wiki/Cross-site_request_forgery

Esses já devem dar para uma introdução ao tema.

Share this post


Link to post
Share on other sites
bioshock

Nada que eu já não tenha lido por alto assim que vi este tópico, excepto o último link. ;)

Estava à espera que alguém se chegasse à frente e me dissesse o que já haviam experimentado, pois fiquei com a sensação que já tinham experiência em casos práticos.

Para concluir e para quem não estiver com pachorra para procurar aplicações que procurem vulnerabilidades, está escarrapachado na wikipédia.

Firesheep

In October 2010, a Mozilla Firefox extension called Firesheep has exploited and made it easy for users of unencrypted public Wi-Fi to be attacked by session hijackers. Websites like Facebook,Twitter, and any that the user adds to their preferences allow the Firesheep user to easily access private information from cookies and threaten the public Wi-Fi users personal property.[6] Only months later, Facebook and Twitter responded by offering (and later requiring) HTTP Secure throughout.[7][8]

WhatsApp sniffer

An app named "WhatsApp Sniffer" was made available on Google Play in May 2012, able to display messages from other WhatsApp users connected to the same network as the app user.[9]WhatsApp uses an XMPP infrastructure with unencrypted, plain-text communication.[10]

DroidSheep

DroidSheep is a simple Android tool for web session hijacking (sidejacking). It listens for HTTP packets sent via a wireless (802.11) network connection and extracts the session id from these packets in order to reuse them. DroidSheep can capture sessions using the libpcap library and supports: OPEN Networks, WEP encrypted networks, and WPA/WPA2 encrypted networks (PSK only) This software uses libpcap and arpspoof.[11][12] The apk was made available on Google Play but it has been taken down by Google. The source is available here

CookieCadger

CookieCadger is a Java app that automates sidejacking and replay of insecure HTTP GET requests. Cookie Cadger helps identify information leakage from applications that utilize insecure HTTP GET requests. Web providers have started stepping up to the plate since Firesheep was released in 2010. Today, most major websites can provide SSL/TLS during all transactions, preventing cookie data from leaking over wired Ethernet or insecure Wi-Fi. Cookie Cadger is the first open-source pen-testing tool ever made for intercepting and replaying specific insecure HTTP GET requests into a browser. Cookie Cadger is a graphical utility which harnesses the power of the Wireshark suite and Java to provide a fully cross-platform, entirely open-source utility which can monitor wired Ethernet, insecure Wi-Fi, or load a packet capture file for offline analysis. Cookie Cadger has been used to highlight the weaknesses of youth team sharing sites such as Shutterfly (used by AYSO soccer league) and TeamSnap. [13] The binary and source can be downloaded here

Edited by Rui Carlos
  • Vote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.