Perigos da validação client-side (ou Sempre valide client E server side)

14 F Y

Desenvolvo para a web há praticamente 8 anos. Pude ver muita coisa surgindo, tecnologias, conceitos, frameworks, aplicações, serviços… O bom de aprender cedo a desenvolver é que você presta atenção as falhas dos outros para não comete-las em seus projetos. Já vi absurdos completos, como um site em que os dados do login eram enviados via GET, usuário e SENHA, plaintext, na url de destino… Outros erros comuns, que por vezes me deparo são mais mascarados, mas qualquer desenvolvedor com o mínimo de experiência os conhece e deve tentar evitá-los. Um exemplo é SQL Injection… a técnica é conhecida desde sempre, no entanto, grandes portais ainda são vulneráveis a este “ataque” trivial, que qualquer usuário pode realizar. Já vi o site de um jornal importante, de grande circulação, abrindo as pernas para um “‘or 1 = 1’ ” colocados como usuário e senha… Mas o foco deste post não é este tipo de problema. Quero discutir aqui sobre outra fragilidade de aplicações web, ainda mais fácil de tratar do que SQL Injections ou XSS: Confiar na validação client-side.

Muita gente que desenvolve aplicações web atualmente, vem do mundo da programação desktop normal. Ao validar um campo (um textbox por exemplo), basta validar o valor inserido pelo usuário e processar aquele valor normalmente (se for o caso de inserção em banco de dados, vale a pena colocar validação no banco também, tanto para desktop como principalmente para web). Se quiser desabilitar algum campo, apenas desabilite ele na interface gráfica e pronto, o usuário não vai ter acesso à ele (não na prática, com facilidade suficiente). Ao desenvolver para web, assumir isto pode ser fatal para sua aplicação.

Modificar o conteúdo exibido em uma página, ou mesmo alterar os valores enviados via POST são atividades triviais, que um usuário com conhecimentos mínimos de HTML e/ou do protocolo HTTP podem fazer, usando complementos para o Firefox como o Firebug e o TamperData.

Através do Firebug, é muito fácil alterar por exemplo, o valor de um <option>, para enviar o valor que o usuário desejar, ao invés dos valores pré-definidos. Remover um “disabled” de um input checkbox ou radiobutton é trivial. Com a mesma facilidade, podem ser removidas as chamadas às funções javascript que realizam validação client-side. Confiar em validações feitas em javascript já não é algo muito inteligente, pois praticamente qualquer browser tem opções fáceis de desabilitar a execução de tais scripts.

A validação client-side no entanto não deve ser esquecida. Para o usuário honesto, sem intenção de quebrar o sistema ou explorar vulnerabilidades, ela é muito útil, diminuindo o tempo de resposta caso algum dado esteja incorreto (evitando que os dados sejam enviados, processados pelo servidor, verificados como incorretos e só então ser enviada uma mensagem de erro para o cliente corrigir os dados não conformes), melhorando assim a experiência do usuário.

Frameworks como ASP.NET oferecem facilidades para o desenvolvedor no momento de validar tanto client como server side. Os componentes de validação realizam uma validação client-side, no entanto, todas as verificações são novamente realizadas no momento em que os dados chegam no servidor. Caso estes não sejam válidos, Page.IsValid irá retornar false, e cabe ao desenvolvedor realizar uma verificação ao valor desta propriedade antes de usar os dados. No entanto, deve-se escolher corretamente as validações a serem realizadas em cada cenário, caso contrário, ainda assim poderão passar dados que não deveriam.

Se você acredita que isto é muito teórico, não acontece na prática, está enganado. Nestes dias, um amigo meu foi se inscrever em um curso. Eu e outro amigo já haviamos conseguido nos inscrever, mas as inscrições eram gratuitas, e as vagas haviam se esgotado quando este outro amigo tentou. Quando analisamos a página (escrita em ASP puro, não ASP.NET), percebemos que o radiobutton para escolher o curso que ele desejava estava com um disabled. Resolvemos alterar via Firebug (apenas remover o atributo disabled=”disabled” da tag), selecionar o curso e enviar o formulário. Resultado: Inscrição realizada com sucesso, e quando ele foi ao curso, estava o nome dele lá na lista de inscritos… Até certificado ele recebeu, tudo normal.

Num caso destes, teria que ser verificado se ainda existiam vagas no momento em que o servidor recebe a solicitação. Não precisaria nem de Firebug para um sistema que apenas valida client-side receber mais candidatos inscritos do que deveria. Uma página guardada em cache visitada antes do fim das vagas poderia inscrever várias pessoas. Outro cenário possível era se existisse apenas uma vaga aberta, mas 5 usuários tivessem carregado a página de inscrição ainda com esta vaga restante. Todos eles conseguiriam se cadastrar pela falta de uma validação server-side.

Neste caso, o efeito foi inofensivo. Não faltou lugar, comida (ótimo coffee-break por sinal 🙂 ) nem nenhum outro recurso necessário ao bom andamento do curso por causa desta inscrição adicional. No entanto, cenários em que o dano causado pela falta de verificações semelhantes podem ser consideráveis não são difíceis de imaginar.

Fica o recado, SEMPRE valide seus dados server-side para evitar problemas! Apesar do “trabalho” adicional (que varia consideravelmente dependendo da tecnologia que você estiver usando), vale a pena para garantir o comportamento que você ou seu cliente esperam do seu sistema.


Bichano.NET – Desenvolvendo aplicações para o Orkut

11 F Y

Pessoal,

Eu, Lucas Mello, João Paulo Oliveira e Flávio Almeida conseguimos finalmente botar nossa aplicação do Orkut lá dentro. Depois de várias semanas lutando pela aprovação, conseguimos que o pessoal do Orkut aprovasse. Por sinal, todos os agradecimentos possíveis e imagináveis pra esse pessoal que avalia e testa os aplicativos antes de serem aprovados. Eles realmente vão a procura de bugs que nós, desenvolvedores sem uma equipe de testes não conseguiamos imaginar.

Para acessar o Bichano.NET, você pode ir simplesmente em http://www.bichano.net, que você será redirecionado para nossa aplicação lá dentro do Orkut, ou ir direto em http://www.orkut.com.br/Application.aspx?appId=523254528764 e adicionar. Mas enfim…

O QUE É O BICHANO?

O Bichano.NET é um aplicativo para o Orkut que visa unir as pessoas que possuem pets. Com o Bichano, você pode ter um “mini-perfil” de seu pet, com foto e tudo mais, dentro do seu perfil do Orkut. Ao ver o aplicativo inteiro, você pode criar perfis de novos pets, pode procurar e adicionar outros pets como amigos, enviar recados para outros pets, criar a agenda de seus animais e procurar por pets de mesma espécie/raça que morem na mesma cidade que você. Com isso você pode encontrar pessoas para trocar informações, para cruzar seus pets e várias outras atividades.

E como é que nós fizemos o Bichano? Seguinte… o Bichano está participando de um concurso de aplicações para redes sociais organizado pela Mentez (http://www.mentez.com). Com isso, recebemos dos organizadores um servidor e uma base de dados online para trabalhar… mas com qualquer máquina que fique ligada 24 horas na net, e que você possa acessar externamente através de um endereço fixo (eu ouvi você falar “DynDNS” (http://www.dyndns.com) ou “No-IP” (http://www.no-ip.com) ?), ou até mesmo com os serviços de hospedagem gratuita que existem por aí, dá pra desenvolver.

Primeiros Passos

A primeira coisa que você deve fazer para desenvover uma aplicação pro Orkut é pedir acesso ao sandbox (sandbox.orkut.com). É nele que você vai dar os primeiros passos de sua aplicação, até ela estar madura o suficiente para ser aprovada pelo time do Orkut. Você pode pedir este acesso através deste link: http://code.google.com/support/opensocialsignup/. Infelizmente, eles tem uma pequena falha, e não enviam um email para você avisando que sua conta está pronta para acessar, logo, espere umas 24 horas e tente, provavelmente você já vai ter acesso. Enquanto isso, vá lendo a api de OpenSocial, que é a maneira que você tem de se comunicar com a rede social, podendo pegar alguns (poucos, pouquissimos…) dados do usuário entre outras coisas.

O que vou usar para desenvolver?

Você pode usar qualquer coisa… Nós fizemos nosso aplicativo com .NET, mas existem outros, como o (excelente, por sinal) TypeRacer e aquelas aplicações do globoesporte que são desenvolvidos em várias outras tecnologias. A nossa escolha por .NET (assim como qualquer outra escolha que “exija” que a página vá dentro de um iframe, como PHP ou Java), acarretou em uma série de dificuldades, pois por questões de segurança, os browsers não permitem que a página interna do iframe chame funções de javascript da página externa ao iframe… isso tira 99% das coisas legais que dá pra fazer com OpenSocial… mas o 1% ainda é bem legal.

A alternativa, pra você poder usar OpenSocial de verdade, é usar Google Gadgets. Com isso, você escreve no XML que é enviado ao Orkut e pode chamar tudo que está pronto lá.

Dificuldades

Além do pouco conhecimento na API e em como usá-la com .NET, uma coisa que foi séria no desenvolvimento do Bichano foi a quantidade de informações desencontradas que existem na net… Em um site do google, falando só da API OpenSocial, você se interessa por uma funcionalidade X… daí, quando vai usar na sua aplicação no Orkut, nada… Normal. Cada rede social tem sua implementação de OpenSocial, e ainda falta MUITA coisa… principalmente um esquema que dispensaria o uso de IFRAME e provavelmente serviria para fazer as chamadas de OpenSocial.

Coisas Legais

Putz, dá pra aprender muita coisa, você começa a prestar mais atenção nas requisições que sua página vai fazer, aprende algumas alternativas de como fazer as coisas… enfim, é muito divertido. E quando o pessoal do Orkut aprova, e você vê sua aplicação sendo acessada, a sensação é MUITO boa!

Só pra se ter uma noção, agora, às 3:45 da madrugada, momento em que estou com mais dois amigos da equipe de desenvolvimento do Bichano.NET aqui no Centro de Informática da UFPE, a aplicação conta com 3650 usuários cadastrados e quase 18000 pageviews… em 2 dias e meio no ar!

Enfim, quem quiser qualquer dica, ajuda, apoio ou qualquer outra coisa, entra em contato que eu vejo o que dá pra fazer!

Ai vão algumas coisas legais de ler pra começar a desenvolver pra o Orkut:

http://code.google.com/apis/opensocial/docs/ – API de OpenSocial

http://code.google.com/apis/orkut/docs/orkutdevguidelines.html – Guidelines para aplicações para o Orkut

http://www.google.com/webmasters/gadgets/ – Google Gadgets


Comentários em ASP.NET

4 F Y

Bem pessoal, desculpem pela inatividade dos últimos dias. Esse vai ser um post bem curto, mas que pode esclarecer uma dúvida muito comum, que várias pessoas (alguns dias atrás, eu estava neste grupo…) compartilham.

Para quem é acostumado a escrever código html na mão, é um ato quase automático digitar <!-- --> para escrever um comentário. Comentários em XML também são escritos usando esta tag. Logo, seria natural tentar usar isto para tentar comentar um trecho de código em algum arquivo aspx/ascx. Para completar, ao usar esta tag, seu código finaliza o Build sem erros e vai pro browser. Só então você descobre que não dá pra comentar usando ela.

O problema é que este comentário é “client-side”. Seu browser irá ignorar o que estiver dentro da tag <!-- -->, e o interpretador do Visual Studio também, pois é uma tag válida. As tags de ASP.NET são interpretadas do lado do servidor, e não importa se seu código “<asp:Label ID="naoQueroQueOUsuarioVejaIssoAgora" runat="server">” está dentro ou fora desse tipo de comentários, o analisador, no momento de “criar” a página que será enviada ao cliente, vai ler o conteúdo interno da tag e ainda lançar uma exceção. Confesso que me passei um bom tempo até descobrir como resolver isto.

A solução é usar a marcação de comentários server-side. A maneira de usar é identica ao que já estamos acostumados, só muda a tag. Ao invés de <!-- -->, usa-se <%-- -->. Pronto, pode colocar o que quiser entre essa tag, o código será solenemente ignorado pelo analisador, e nem vai para o browser do seu cliente, ao contrário do comentário client-side, que é enviado e fica a cargo do browser ignorar.

Uma última dica, que serve tanto para o code-behind como para os aspx/ascx, e que aprendi numa visita de André Furtado a uma das reuniões iniciais da célula de estudos CIN.NET, da qual participo, é usar o atalho “CTRL+K+C” para comentar e “CTRL+K+U” para descomentar um trecho de código. Se eu tivesse lembrado disso na primeira vez que precisei comentar um trecho de código aspx, nunca teria tido o problema :p