Mitigando o ataque 'firesheep' na camada de rede?

4

Quais são os pensamentos do administrador sobre a mitigação do ataque 'firesheep' para servidores que eles gerenciam?

O Firesheep é uma nova extensão do firefox que permite que qualquer pessoa que o instale na sessão de sidejack possa descobrir. Ele faz sua descoberta farejando pacotes na rede e procurando por cookies de sessão de sites conhecidos. É relativamente fácil escrever plugins para a extensão para ouvir cookies de sites adicionais.

De uma perspectiva de sistemas / rede, discutimos a possibilidade de criptografar todo o site, mas isso introduz carga adicional nos servidores e parafusos com indexação de sites, ativos e desempenho geral.

Uma opção que investigamos é usar nossos firewalls para fazer o SSL Offload, mas como mencionei anteriormente, isso exigiria que todo o site fosse criptografado.

Quais são os pensamentos gerais sobre proteção contra esse vetor de ataque?

Eu fiz uma pergunta semelhante no StackOverflow, no entanto, seria interessante ver o que os engenheiros de sistemas pensavam.

    
por pobk 25.10.2010 / 19:37

5 respostas

5

Desde que os dados da sessão sejam passados entre o servidor e o cliente, você estará vulnerável a algum tipo de invasão em redes não seguras. A natureza sem estado do HTTP praticamente garante que qualquer pessoa com seus dados de sessão possa fingir ser você para o servidor.

Então, o que fazer? Você precisa transmitir com segurança as informações da sessão do servidor para o cliente, sem que os intrusos possam interceptá-la. A maneira mais fácil e certa é tornar seu site todo HTTPS, ou seja, sem tráfego não criptografado. Isso é muito fácil de implementar, já que você não precisa alterar seu aplicativo, apenas os servidores. A desvantagem é que aumenta a carga nos seus servidores.

Se isso não for uma opção, você precisará de alguma forma ofuscar os dados da sessão que o servidor passa para o cliente. E o cliente precisa de algum script para "desobstruir" os dados da sessão para passar de volta ao servidor na próxima solicitação. Sim, isso é "segurança através da obscuridade", e todo mundo sabe que isso não funciona. Exceto quando isso acontecer. Desde que o seu site não seja um alvo de alto valor, obscurecer os dados da sessão impedirá que os usuários casuais desta coisa 'firesheep' sequestrem seus usuários. Somente quando / se o seu site ficar no radar de alguém disposto a fazer engenharia reversa de sua ofuscação, essa técnica de mitigação falhará.

    
por 25.10.2010 / 22:08
4

Por que você teria que criptografar todo o site?
Basta configurar um subdomínio, login.yourcompany.com, criptografar esse bit, definir o sinalizador de segurança no cookie (interrompe a transmissão de qualquer coisa que não seja um canal seguro) e configurar o servidor de login com uma relação de confiança interna quero fazer isso é com você) para o resto da aplicação.

    
por 25.10.2010 / 19:48
2

Veja a proposta / código de Ben Adida para "SessionLock Lite". É certo que não oferece proteção contra ataques ativos ou escutas e é vulnerável a ataques de curta duração. Mas isso pode ajudar no prazo imediato enquanto você cria uma solução real de SSL: link

    
por 07.01.2011 / 16:53
0

Credenciais sempre devem ser criptografadas, nunca aprovadas. O que há de tão difícil nisso?

    
por 25.10.2010 / 19:41
0

De uma perspectiva de administração local:

Para que o firesheep trabalhe em uma rede com fio, o invasor terá que realizar um envenenamento por ARP na infraestrutura do switch. O tráfego de e para outros computadores nunca chegará ao PC atacante, a menos que eles explorem a rede pela primeira vez.

Da perspectiva de um provedor de serviços:

Eu gostaria que meu site, ou pelo menos qualquer tráfego de autenticação ou cookie, fosse criptografado por SSL.

Da perspectiva do usuário final:

Eu gostaria que o provedor mantivesse minha sessão segura, então nem preciso pensar em digitar "https: //". Isso deveria me forçar a ser seguro.

    
por 07.01.2011 / 20:19