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

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!

Sugestão de Livro: Head First Design Patterns

Você não está sozinho! Em algum lugar do mundo, alguém reparou a dificuldade das pessoas em entender design patterns e decidiu facilitar a nossa vida. Essa(s) pessoa(s) resolveram escrever um livro sobre design patterns, e é dele que vou falar.

Estava eu em um avião, e iria encarar umas horas de viagem a alguns meses atrás. Felizmente ao meu lado estava @Tiago__Farias, e na sua mochila estava um livro chamado Head First Design Patterns. Conversamos um pouco e falamos sobre alguns livros, e foi quando ele me emprestou o livro para que desse uma lida no vôo. Como tinha interesse em conhecer design patterns, comecei a ler right away o livro naquele momento.

O primeiro capítulo desse livro é o mais genial de todos (ainda mais se você não conhecer a série Head First, pois será uma surpresa, como foi para mim). Você começa a ler o livro e ele vai falando de forma muito didática (ensinando para os burros, do jeitinho que eu gosto :P) a mágica de orientação a objeto desde o início, falando sobre princípios de design, utilização de interfaces, etc e BANG! Quando você se dá por conta ele já ensinou um design pattern e você nem sentiu! Isso anima a você continuar a ler e aprender o restante dos design patterns. Obviamente o livro pode servir como um livro de referência, mas os capítulos iniciais são leitura obrigatória ao meu ver.

Não precisa nem falar que depois dessa viagem que eu conheci o livro (que foi emprestado) eu comprei na hora o meu exemplar na amazon!

Para quem não conhece e se interessou aqui tem o capítulo 3 para download que descreve e explica brilhantemente o padrão Decorator.  Boa degustação!

O que é Software Craftsmanship?

Por meio de um twitter de @lucabastos, terminei vendo uma apresentação de @sandromancuso & @activelylazy sobre essa nova onda rolando a algum tempo já, e terminei conhecendo por acaso esse movimento chamado de Software Craftsmanship.

Confesso que não conhecia ainda esse movimento mas pela apresentação que vi no slideshare me pareceu bastante interessante e já simpatizei de cara (inclusive depois de estudar um pouco o movimento eu assinei o manifesto, e no momento que assinei existia 213 brasileiros que já haviam assinado) .

Se formos traduzir literalmente Software Crafsmanship significa algo em como “Software Artesanal” e o movimento gira em torno de sermos melhores artesões.

Apesar do manifesto do Software Craftsmanship só ter sido criado em 2009, suas raízes vem desde 1999, com a publicação do conhecido livro Pragmatic Programmer, que trata sobre como ser um programador melhor, em diversos sentidos da palavra.

Uma definição de software craftsmanship é a seguinte:

It’s a lifestyle where developers choose to be responsible for their own careers and for improving their craft, constantly learning new tools and techniques. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development.

Figuras renomadas, como Robert C. Martin (ou Uncle Bob) que inclusive participou da criação do manisfesto ágil , apoiam o movimento. O próprio Uncle Bob escreveu:

The original torch of the Agile message has changed hands, and is now being carried by the Software Craftsmanship movement.

Segundo ele mesmo colocou, o movimento do software craftsmanship seria uma “extensão” do manifesto ágil, obviamente sem anular os pontos que foram citados no manifesto ágil. Dessa forma, vamos analisar o “manifesto do software artesanal”, que tem os seguintes valores:

Not only working software, but also well-crafted software;
Not only responding to change, but also steadily adding value;
Not only individuals and interactions, but also a community of professionals;
Not only customer collaboration, but also productive partnerships.

Muito legal esse manifesto, e como podemos perceber o ponto central por trás desses valores é sermos melhores programadores, e consequentemente nossos artesanatos serão bem melhores do que são hoje em dia. Além disso, é preciso parcerias onde possamos nos desenvolver, formando uma comunidade de artesãos de software capacitados.

@sandromancuso & @activelylazy em sua apresentação falaram das características do papel de artesão de software. Listei algumas aqui:

  • Nós controlamos nossas carreiras;
  • Artesão de software não é uma profissão comum daquelas que dá 18:00 e vamos pra casa;
  • Intolerância a código ruim;
  • Somos profissionais e somos pragmáticos;
  • Nós estamos continuamente aprendendo e interessados em aprender;
  • Nós nos importamos e somos orgulhosos do nosso trabalho 🙂

Para sermos melhores artesãos, é sempre preciso:

Criatividade, Visão Crítica, Base teórica e Habilidades Práticas;

Além disso, é preciso estar ligado no que Software Craftmanship NÃO É:

  • NÃO É um certificado
  • NÃO É um curso
  • NÃO É um livro

Software Craftmanship é ATITUDE!

Somos maus programadores, aceite isso! Será mesmo?

Não sei quantos de vocês acompanharam alguns dos últimos posts que rolaram em alguns blogs famosos, mas Jared Richardson no Blog da Agile Zone publicou um post entitulado “You’re a Bad Programmer. Embrace It.” que foi bastante acessado e um tanto quanto polêmico.

Jared, em seu post, fala que somos péssimos desenvolvedores:

How many developers think they’re good programmers? We’re not. We’re all fairly bad at what we do. We can’t remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we’ve spent years, in some cases decades, learning? We can’t even type the syntax properly, so we have compilers that check and correct it for us.

Até parece fazer sentido né? Só que não faz! Na verdade, é óbvio que existem bons e maus programadores (assim como qualquer outra profissão) e o fato de utilizarem utilizarem ferramentas não os torna maus programadores (talvez até o fato de utilizarem determinadas ferramentas para facilitar seu trabalho os torne BONS).

É como dizer que um mecânico é bom se ele apertar um parafuso de uma determinada peça com a mão, e não com uma chave de fenda.

Stephan, dono de outro blog famoso de TI, o Code Monkeyism, leu esse post do Jared e não gostou muito também 😛 Stephan então postou um resposta entitulada “Você é mesmo um mau programador?” e então ele critica diversos trechos do post original do Jared.

O post do Stephan (do Code Monkeyism) ficou muito legal e ele embasou cada ponto de crítica que fez ao nosso caro Jared. Não preciso nem dizer que concordei com o Stephan.

Até que dá pra entender que o intuito original do post de Jared era dizer que existem ferramentas que podem nos auxiliar a ser melhores programadores e a evitar alguns tipos de erros, o problema maior foi a fundamentação do problema que foi muito rasa.

O post de Stephan em resposta ao posto original do Jared termina da seguinte forma:

There are good and bad programmers. The good one are those who want to become better, are interested in their craft, the bad ones are those who do 9 to 5 jobs without any interest in their profession.

Existem bons e maus programadores. Os bons são os que querem se tornar ainda melhores, estão interessados no que produzem…

Um projeto pode ser ágil sem SCRUM ou KANBAN?

Hoje em dia muito se fala sobre Scrum, Kanban, e estes conceitos estão realmente na moda atualmente. Primeiramente gostaria de dizer que não tenho nada contra o Scrum ou o Kanban, muito pelo contrário, uso Scrum a algum tempo e percebo no dia-a-dia os benefícios de tais práticas.

E então chegamos na palavra que eu queria chegar: Prática. Tanto o Scrum quanto o  Kanban e também o XP (eXtreme Programming) são práticas comuns (formas de fazer, de conduzir) comuns no mundo ágil. Muitas pessoas param por aqui quando estão falando sobre desenvolvimento ágil, mas uma pergunta importante precisa ser respondida: O que faz uma metodologia/prática ser considerada ágil? Nesse momento então chegamos ao ponto crucial que são os princípios e valores que estão por trás do que se considera ágil. Todas as práticas que se consideram ágeis é porque valorizam os pontos levantados no manifesto ágil:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Sabendo agora que existem princípios por trás de determinadas práticas, podemos então responder a pergunta se um projeto pode ser ágil mesmo sem utilizar Scrum ou Kanban, e a resposta é ‘SIM’! Basta que estejamos ligados a esses princípios.

Sendo assim, o contrário também pode acontecer: Você pode “utilizar” Scrum, ter post-its na parede, dividir seu projeto em iterações (sprints), fazer Scrum Daily Meetings e ainda NÃO SER ÁGIL!

Então sabemos mais importante do que Scrum ou Kanban, são os principios e valores por trás dessas práticas. No próximo post vou tentar detalhar mais o manifesto ágil e explicar melhor esse texto que só tem 4 linhas mas é enorme.

XSS na mídia

Nos últimos dias quem acompanhou as notícias do mundo de TI deve ter visto ou ouvido sobre o bug do on mouse over do twitter ou do Bom Sabado do Orkut.

Entrando um pouco mais em detalhes sobre a causa do problema vamos ver que a falha de segurança foi ocasionada pelo famoso Cross-Site Scripting ou simplesmente XSS (é famoso mas muita gente não conhece, inclusive eu não conhecia 😛 #ShameOnMe). Para começar, vamos a uma rápida definição de XSS:

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pagesviewed by other users.

Quem já ouviu falar em SQL Injection? Pois bem, XSS é uma vulnerabilidade semelhante só que utilizando javascript, algum usuário insere código javascript malicioso (pegar as sessões de usuário, redirecionar navegação para outro site mais malicioso ainda, etc) em algum formulário na web, e BANG! quando alguém vizualizar aquelá informação no sistema, o código malicioso será executado (e possivelmente propagado, como no caso do bug do orkut).

Meu amigo Edwin Carlo me apresentou o OWASP (Open Web Application Security Project) que é uma organização focada em melhorar a segurança dos sistemas web, e eles mantém um rank das vulnerabilidades mais comuns, e adivinha? XSS é a segunda (só perde para injections tipo sql injection).

A boa notícia é que existem soluções fáceis para evitar ataques do tipo XSS, e aqui vai um redirect para outro amigo meu, Tiago Farias que fez um post bem legal e detalhado sobre como criar um Filtro Anti-XSS em Java. Você, meu amigo desenvolvedor, por favor atente para isso a partir de agora 🙂