Abrindo o Pote de Cookies da Web

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!.

Anúncios

Android: Vale a pena estudar?

Eu decidi (nesses últimos dias)  estudar android (quem acompanhou meu twitter deve ter visto). A motivação para que eu começasse a estudar é bastante simples, o android foi criado pelo google, e o google não entra para brincar em nada.

Aqui vão alguns outros pontos importantes a respeito do android é que o sistema está em constante evolução, e a última versão 2.2 foi lançada em Julho/2010. Além disso um ponto MUITO importante e TOTALMENTE relevante é o Android market que possui diversas aplicações desenvolvidas para android, muitas delas free, e desde fevereiro de 2009 começou também a aceitar aplicações pagas. Somente 9 países suportavam aplicações pagas, e desde o mês passado o google ampliou o suporte a aplicações pagas para mais 20 países (incluindo o Brasil).

E as boas notícias não param por aí, o android market que no início de 2010 tinha cerca de 20.000 aplicações acabou de  alcançar a marca de 100.000 aplicações no mês passado (out/2010). Quer um maior sinal de que o android realmente está começando (começando ou consolidando) a garantir o seu lugar ao sol no mercado mobile?

Eu vou dar um sinal ainda maior já que você quer 😛 Como vocês sabem o android não está preso a um determinado hardware, nem a um determinado manufacturer, isso é bom pois aumenta o leque  de escolhas do consumidor. Os smartphones equipados com android superaram as vendas do iPhone nos USA em agosto desse ano. E não é só um fenômeno acontecendo nos EUA, houve um aumento de 886% (isso mesmo…. oitocentos e oitenta e seis porcento) da produção mundial de dispositivos com android em relação ao ano anterior.

Eventualmente você vai se ver em um futuro próximo trabalhando com algo relacionado a android, seja desenvolvendo aplicações, modificando alguma versão do android para utilizar em algum dispositivo móvel, ou simplesmente sendo usuário de um celular com android!

Essa é a motivação inicial para aprender android. O próximo post para android será mais técnico, aguardem!