Esse post é “mais ou menos” uma tradução junto com algumas opiniões de um post de um blog bem legal chamado Coding Horror mantido por JeffAtwood. Para quem não conhece Jeff Atwood ele é o cara que criou o site Stack Overflow que você provavelmente  já acessou. Decidi fazer essa “tradução” pois o tema do post é muito interessante e é importante estarmos ligados nesse tipo de coisa. O nome do post original é “Breaking the Web’s Cookie Jar” e aqui vai a versão portugês:

O plugin do firefox chamado Firesheep causou um “buruçu” (traduzindo: um reboliço, uma movimentação, um zum-zum-zum), e com motivo. Esse plugin funciona da seguinte forma:

• Você conecta em uma rede Wifi que não exija senha para conectar;
• Instala o plugin Firesheep;
• Espera um pouco e automaticamente o plugin vai capturando os acessos de outras pessoas dessa rede e lhe mostrando a imagem de login da pessoa e o serviço que ela está logada (ex. twitter, facebook, etc etc);
• Clique em algum usuário desses e instantaneamente você estará logado como aquela pessoa no serviço que ela está logada.

Caramba! Esse cara que implementou o firesheep deve ser o cara né? Não exatamente. Na verdade o trabalho maior foi o de empacotar isso tudo e criar uma interface legal como plugin do firefox do que propriamente “hackear” a sessão de outro usuário em determinado site que ele esteja logado.  Essa captura da sessão do outro usuário está longe de ser alguma forma de “hack” ou de “mágica”. Na verdade, o bom da audiência que o firesheep está tendo é que ele evidencia um problema fundamental de arquitetura da web, mais especificamente da questão de sessões salvas em cookies. A única forma de um site saber quem está acessando, é através de identificadores enviadas no cabeçalho das requisições HTTP a cada click que você faz em um link.  Dentro do HTTP header existe a informação do cookie, que  diz quem você é ao site que vocês está acessando. Para a sua surpresa essas informações do cookie trafegam em forma de text puro (plain text) sem criptografia. Isso significa que qualquer pessoa (que estiver na mesma rede que você  ou em alguma posição e que consiga vizualizar os pacotes de rede) pode recuperar essas informação e imediatamente “incorporar você” em qualquer site que você esteja logado. Agora que você já sabe em partes como o cookie funciona, você já pode entender melhor o que o Firesheep faz:

• Escuta o tráfego HTTP
• Espera um HTTP header de um site conhecido
• Isola a parte do cookie que identifica o usuário
• Cria uma nova sessão no browser com o cookie e nesse momento o site que você está acessando pensa que você é outra pessoa.

Então tudo que o firesheep faz é “escutar” requisições HTTP e se aproveitar de informações do cookie presente nelas. E essa é a forma que a internet funciona desde 1994, quando o cookie foi inventado.

Então você deve estar se perguntando porque isso não era um problema antes? Porque a alguns anos atrás, vamos dizer 2003, esse problema não existia?

• Redes wireless públicas não eram tão comuns, e só se popularizaram a alguns anos atrás;
• A grande maioria das pessoas não navega anonimamente hoje em dia, você está quase o tempo todo “logado” em algum site, seja email, facebook, twitter, etc etc;
• As ferramentas para escutar o tráfego em redes wireless também estão um pouco menos primitivas hoje em dia;
• Os sites que “realmente” precisavam de segurança no tráfego de informações migraram para HTTP encriptado, ou HTTPS;

O HTTPS foi inventado em 1994, mesmo ano que o cookie, e isso não foi coincidência. Os próprios criadores do cookie, sabiam desde o início que eles precisariam de alguma forma de proteger os dados que trafegam do cookie. Então desde as eras mais primitivas ( como em 2003 😛 ) qualquer banco ou site que tenha autenticação, e que se preocupe um pouquinho nem pensava em usar HTTP puro.

O “buruçu” em torno do Firesheep é justificado pois na verdade O Pote de Cookies da Web sempre esteve aberto, e nós nunca fizemos nada. O que fazer então?

Você pode pensar estar pensando que quem precisa de mais segurança deveria trafegar suas informações de forma encriptada, como usando o HTTPS, mas essa não é uma solução muito adequada. Você teria que proteger todo seu tráfego de informação somente por conta de um pedaço do header (outro pedaço) de um HTTP request. Parece um canhão para matar uma formiga.

Embora não saibamos o que vai acontecer para “fechar” o pote de cookies pelo menos ficam algumas dicas que o firesheep nos trás:

1. Temos que ter cuidado com o que acessamos em uma rede wifi aberta. Essa é o melhor presente que o firesheep nos trouxe. Abriu nossos olhos para esse problema tão velho e tão presente. O ideal é que em redes sem criptografia você simplesmente navegue anonimamente (sem logar em nenhum serviço), como ler artigos, blogs, noticias, etc.
2. Tenha sempre o hábito de acessar webmail via HTTPS. Mais importante que todos os serviços que você pode acessar, o seu email é sua identidade maior! Se você perder ele, você perde quase tudo! Então cuidado ao acessar webmail, e se seu email não suporta HTTPS, procure outro.
3. Use HTTPS em seus sites já que não existe outra forma melhor (por enquanto). Já passamos do tempo em que HTTPS é coisa só de banco e de transação financeira. Se você precisa proteger, use!  HTTPS não é mais tão caro quanto antigamente então use, e cobre dos sites que você acessa que também o usem.

A moral da história é que esses são direcionamentos muito genéricos, mas que já são um avanço quanto a educação das pessoas ao utilizarem redes wifi abertas. E quanto ao Firesheep, nós vimos que ele Não Abriu o Pote de Cookies da Web, o Pote já estava aberto! Espero que isso tudo sirva como motivação para criarmos uma saída melhor que cookies trafegando em HTTP puro!.