Um dos ataques mais comuns a sistemas web na atualidade é o sequestro de sessão ou mais conhecido como “Session Hijacking”. Hoje eu gostaria de falar um pouco sobre o assunto, apresentando uma aplicação prática de como roubar uma sessão, invadir um site e acessar a conta da vítima.
HTTP é Stateless
A facilidade de se roubar uma sessão se da pelo justo fato do HTTP ser um protocolo de comunicação sem estado e por isso necessitar que um número de identificação trafegue dentro de todas as interações que um navegador de internet fizer para se comunicar com a solução web.
Como isso funciona?
Todas as vezes que você acessa uma aplicação web, o sistema te envia um numero único que será usado para identificar que você é você durante o uso da aplicação ao longo do tempo. Ou seja, todas as vezes que você entrar no site após abrir o navegador de internet, o sistema vai te enviar um número como por exemplo: 123ABC que será seu identificador único. O navegador de internet foi programado para armazenar esse número e envia-lo de volta todas as vezes que você interagir com o sistema, clicando (link, botão, aba, menu etc) na página, fazendo a solução web processar seu pedido e saber que você é você. A questão é que esse identificador fica disponível e visível para ser roubado por qualquer pessoa que tenha conhecimentos mínimos de manipulação de rede e ou protocolo HTTP.
Como roubar o identificador?
O identificador pode ser facilmente roubado de varias maneiras. Segue alguma delas:
1. Trafego HTTP – qualquer pessoa que tenha conhecimentos básicos de rede pode facilmente usar uma ferramenta chamada de “Sniffer” para interceptar todos os pedidos de internet trafegados em uma rede, visualizando todo o conteúdo do protocolo e assim localizar esse identificador.
2. No Navegador – o identificar pode ser acessado via javascript usando o comando “documento.cookie”. Isso abre varias possibilidades:
- Qualquer pessoa que saiba escrever código javascript pode executar esse comando no navegador e obter o identificador.
- Pode existir vírus instalados na estação do usuário sem o seu consentimento que também pode obter o identificador manipulando o navegador.
3. Link Malisioso - O usuário pode ser induzido a entrar em um link originário de algum e-mail falso ou de outro site dizendo “depois de logar no seu internet bank, click aqui para atualizar seu cadastro”. O link ou o site falso pode ser programado para ter comandos javascript que extraia esse identificador.
4. Adivinhação – Algumas soluções web tem a geração do número identificar seguindo uma lógica no qual pode ser facilmente adivinhado. Por exemplo, se o último identificador gerado foi ABC123 o próximo poderia ABC1234.
De qualquer forma que o identificador seje sequestrado, o atacante de posse desse número pode então acessar e usar a solução web fazendo o sistema pensar que o atacante é o próprio usuário autenticado.
Exemplo
Você entra no seu site de comercio eletrônico preferido, colocando seu login e senha. A partir disso começa a navegar nos livros, procurando algum do seu interesse. Nesse tempo seu identificador de sessão é roubado por uma pessoa que esta visualizando todo o trafego HTTP da rede e o atacante assim faz comunicação com essa aplicação web de comercio eletrônico fazendo a solução pensar que ele é você usando o sistema. Diante disse, o atacante pode então executar qualquer ação maliciosa que prejudique você e a solução como por exemplo, visualizar e ou alterar suas informações pessoais como endereço, cartão de credito, trocar seu cadastro, gastar seus cupons de vale-desconto ou colocar um endereço de entrega falso, ficando com sua última compra. Tudo depende do cenário da aplicação.
Prática
Vamos para a brincadeira. Hoje vamos invadir o site do Java Ranch muito conhecido pela comunidade Java mundial. O endereço do site é http://www.coderanch.com/forums/user/login e da acesso para a pagina de autenticação:
Vou colocar meu usuário e senha, me autenticando na aplicação.
Veja que eu entro no link “My Profile” e vejo minhas informações pessoais:
Para simular o sequestro de sessão, vou executar um simples javascript no navegador que acessa o número. Eu digito na barra de endereço “javascript:alert(document.cookie)” e obtenho o número da minha sessão estabelecido após me autenticar:
Veja que esse roubo pode ser feito no tráfego, por vírus, spam de e-mail ou qualquer outra coisa que maliciosamente pegue esse número. Repare que o identificar de sessão neste site esta declarado como JSESSIONID=4AD7D9322052B800F6BF03D2811AA895;
Com esse número em mãos, o atacante pode usar qualquer ferramenta HTTP para trocar requisições no site do fórum anexando o ID da sessão roubado. Com isso, o site do javaranch vai responder achando que na verdade é o próprio usuário apenas fazendo mais uma requisição. Para mostrar isso, eu escrevi uma simples aplicação Java que envia um pedido HTTP para o qualquer endereço na internet, no qual eu possa mecanicamente adicionar um número da sessão e com isso simular o cenário. Segue a abaixo o fonte do sistema:
Esse sistema apenas envia uma requisição HTTP para um endereço configurado, anexando qualquer ID de sessão e como resultado imprime no console a página de resposta retornada pela aplicação. Ao executá-lo passando o valor da sessão roubada, o site do javaranch me envia a página de resposta do meu usuário, mostrando todos as minhas informações. Ou seja, o atacante agora pode então acessar o fórum fazendo a aplicação pensar que as requisições originarias da ferramenta de ataque são do próprio usuário logado. A partir dai é muito fácil manipular a ferramenta para gerar requisições que manipulem todos os processos disponibilizados pelo sistema. Caso alguem se interesse nessa ferramenta é só postar um comentário no artigo requisitando que eu prazer em compartilhar.
Como impedir os ataques?
Os responsáveis pelas soluções web devem estar cientes das possíveis vulnerabilidades existentes nas “entrelinhas” tecnológicas da atualidade, juntamente com as questões e situações que envolvem os “ciclos de desenvolvimento” e assim devem implementar contra-medidas que venham inibir cada vulnerabilidade que possam gerar problemas dentro do contexto da negocio da solução.
O sequestro de sessão é apenas um caso de brecha das muitas dezenas existentes hoje no qual eu percebo que maioria dos responsáveis estão na verdade mal preparados e completamente a margem da situação. Para os interessados no assunto segue as minhas dicas de leituras.
Eu me coloco a disposição para qualquer eventual dúvida sobre o assunto. Até a próxima pessoal 
!
“Aquele que supre a semente ao que semeia e o pão ao que come, também lhes suprirá e multiplicará a semente e fará crescer os frutos da sua justiça.” 2 Coríntios 9:10
Uma das novas features do Tomcat 7 é a substituição da antiga implementação do serviço de pool de conexão chamado de Commons-dbcp por uma nova implementação chamada de JDBC Connection Pool. O Commons-dbcp sempre funcionou muito bem para aplicações razoavelmente pequenas acompanhadas de tráfico médio de acesso, não sendo indicado para aplicações grandes, com alto e crescente níveis de tráfico em ambientes multi-core/multi-cpu. Felizmente essa situação foi contornada no Tomcat 7 aonde o JDBC Connection Pool foi implementando justamente para suportar aplicações com alta concorrência e performance. Veja o artigo de Daniel Mikusa explicando a situação.
