DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

Revista MSDN Magazine Edição 01 - Coluna "Encarando o Desenvolvedor"

Artigo Originalmente Publicado na MSDN Magazine Edição 01

msdn01_capa.JPG

Clique aqui para ler todos os artigos desta edição

 

Coluna “Encarando o Desenvolvedor”

por Mauro Sant’Anna

 
Tratando usuários como psicopatas

   Hoje em dia, é comum "meterem o pau" nas grandes empresas de software em conseqüência dos problemas de segurança encontrados em seus produtos. Acredito que a explicação para esses problemas esteja além do "desejo de ganhar dinheiro vendendo artigos defeituosos para os patos", como definem algumas pessoas. Creio também que grande parte do problema resida no fato de que os desenvolvedores, tanto de software como de hardware, tendem a se comportar de maneira ingênua e, conseqüentemente, perigosa.
   Nos gloriosos tempos dos aplicativos cliente-servidor escritos em Clipper, Delphi ou Visual Basic, os desenvolvedores consideravam os usuários pessoas meio bobinhas, mas bem intencionadas (mais ou menos como o chefe O'Hara, do seriado de TV Batman). Os usuários, com sua ilimitada ingenuidade, conseguiam expor os defeitos escondidos até mesmo dos aplicativos mais bem desenvolvidos. Por exemplo, eles pressionavam um conjunto de teclas não esperado ou instalavam combinações inusitadas de hardware, tais como uma impressora matricial russa junto com um mouse fabricado no Congo.
Fomos habituados a criar aplicativos protegidos contra a "imaginação" dos usuários, mas não contra comportamentos intencionalmente maliciosos. Essa premissa orientava não só o desenvolvimento de aplicativos como também de software básico, linguagens de programação e até de hardware.
   Se há dez anos alguém me explicasse o que é preciso para que um moderno vírus ou worm controle um computador, eu simplesmente não acreditaria, tal a complexidade. Por exemplo, em um típico ataque de buffer overflow, o hacker tenta inserir dados codificados de maneira especial que sobrescrevem as áreas de memória que contêm o endereço de retorno da função, de modo a fazer com que este endereço aponte para um trecho de código cuja execução traga algum benefício para o invasor. Há alguns anos, isso pareceria enredo de conto de ficção científica, mas hoje, infelizmente, é comum. Na verdade, a simples existência de um buffer overflow já justifica um boletim de segurança, mesmo que, aparentemente, não haja ninguém se aproveitando da falha.
   Para quem duvida que isso era considerado inconcebível há alguns anos, apresento duas provas: em primeiro lugar, as rotinas de manipulação de caracteres da linguagem C (muito usadas em software básico) são extremamente vulneráveis a esse tipo de ataque; em segundo lugar, as CPUs modernas guardam tanto os dados como os endereços de retorno na mesma pilha de hardware - "Santa Ingenuidade, Batman!". Se fôssemos projetar uma linguagem ou CPU hoje, sabendo o que sabemos a respeito de falhas de segurança causadas por buffer overflow, jamais cometeríamos esses dois erros infantis.
   No que se refere ao desenvolvimento de software e, mais especificamente, de software para a Web (que pode ser acessada do mundo todo), precisamos adotar atitudes drásticas. Nossos usuários podem agir agora como verdadeiros gênios do mal, em vez de ingênuos bem intencionados. O Curinga, em vez do chefe O'Hara.
   Uma das principais conseqüências para o desenvolvedor de software, é que ele precisa tratar tudo que vem do usuário com muito cuidado, como se estivesse lidando com lixo radioativo. Essa regra vale, por exemplo, para URLs, dados enviados por meio de formulários ou campos escondidos. Atualmente, uma das vulnerabilidades mais comuns em aplicativos Web consiste na injeção de comandos SQL em programas que simplesmente concatenam a entrada do usuário com algum texto fixo com o intuito de criar um comando "especial" para o banco de dados.
Infelizmente, precisamos tratar os usuários como potenciais psicopatas criminosos. A época de ingenuidade e despreocupação está irreversivelmente ligada ao passado.





    1 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.



Edson Silva Marques

Sobre o artigo "Submarinos Voadores" que aborda a questão da falta de coerência entre os programas de computadores e o mundo físico, gostaria antes de tudo de dizer que concordo com você , mas ... faltou alguma coisa. Faltou uma analise mais profunda do problema, o artigo peca em apenas mostrar o  problema e dizer a solução, e este é um problema não só do artigo, mas do mundo contemporâneo, ele existe na  medicina onde o paciente se queixa de dor de cabeça para um médico e leva um  analgésico para casa sem nem mesmo saber o que tinha.Quem nunca colocou um “IF mágico” no seu programa sem saber a razão do erro que atire a primeira pedra. Pois bem, vamos pensar um pouco mais sobre o desenvolvimento de software, mas desta vez vamos Pensar, com P maiúsculo sem ficar presos a pré-conceitos, no sentido original da palavra.

 

Quando estamos criando software, estamos na verdade aplicando regras sobre dados. Agora pense um pouco no mundo lá fora, o que existe alem disto? O mundo nada mais é que a aplicação das leis naturais sobre a matéria. Lei natural: os objetos de menor densidade relativa ficam acima dos de menor densidade relativa. Objetos: Submarinos e aviões. Quando aplicamos a lei sobre os submarinos na água, vemos que estes possuem uma “densidade relativa” maior que a água, portanto ficam por baixo dela. Já ao aplicarmos a mesma lei nos aviões, os mesmos são mais “leves” que o ar, portanto voam. Quando estamos desenvolvendo software, estamos criando nossas próprias regras que são aplicadas sobre nossos próprios dados, assim quando estamos criando software estamos criando nosso próprio mundo! Estamos nos tornando Deuses deste mundo! Seja lá o que isto quer dizer. Podemos criar as leis que quisermos, e aplicá-las nos dados que quisermos, no entanto existe uma restrição. Assim como no mundo, uma lei não deve ir contra outra ( por favor digam isto aos políticos atuais! )  em nosso software uma regra não pode contradizer outra. Isto se chama “Modelo”.

 

Este é o grande problema do artigo citado, ele não fala do modelo, apenas das regras. Alias, este é O Problema dos softwares em geral. Não existe um modelo e as regras entram em conflito umas com as outras gerando resultados no mínimo estranhos. Atualmente quando se faz software não se pensa na lógica do programa como um todo, apenas junta-se um monte de regras e pronto, está feito nosso programa. Esquece-se, ou melhor, na maioria das vezes nem se sabe que estamos construindo um mundo! Com suas próprias regras, e estas regras, nem sempre tem que ser iguais as mesmas do nosso mundo físico, ou seja, pode-se existir submarinos voadores no nosso programa, desde que estes tenham sentido no mundo (programa) que estamos criando, mas quando os criamos somos responsáveis pelo que eles podem fazer. Você pode muito bem criar um submarino voador para um jogo de guerra, mas deve levar em consideração o que este submarino pode fazer com os outros componentes do jogo, será que os outros componentes terão defesas suficientes contra o submarino? Será que na hora de implementar seu vôo este não vai “atravessar” um prédio? Desde que saibamos as conseqüências e que a implementação do submarino voador não entre em conflito com nenhuma regra não há porque não implementa-lo. Outra questão importante é o que queremos dizer com “submarino voador” ? Segundo o artigo é algo que não existe e é impossivel de existir no mundo real. Será mesmo? Bom, e avião invisível existe? Existe, e não é a Mulher Maravilha que voa nele. Será que um submarino voador fere as regras de nosso mundo? Segundo o artigo como um submarino tem que ser pesado para afundar este não poderia voar. Acho que alguém já disse o mesmo com relação a um negócio chamado avião: “Como algo mais pesado que o ar pode voar?”, bom se não me engano muitos voam e até caem em nossas cabeças. A questão aqui é a interpretação da regra, avião é mais pesado que o ar mas voa porque sua “densidade relativa” é menor que o ar, é uma questão de tecnologia. Basta tecnologia para fazer um submarino voador. Não existe regra ( lei natural ) que impeça isto. Podemos colocar esta regra em nosso programa se que quisermos evitar submarinos voadores, afinal é o nosso mundo e nele as regras podem ser diferentes. Mas será necessário? E quando os submarinos voadores passarem a existir no mundo real, vamos ter que alterar nosso programa? Será que esta regra não vai entrar em conflito com outra já existente no programa? Programar é a arte de modelar, é aprender a ser DEUS.

 

 

Edson acredita no conhecimento e que siglas como “KISS” são uma desculpa para quem não quer pensar.

 

[há +1 ano] - Responder

 



Publicidade
Autor
Mauro Santanna

já trabalhou com desenvolvimento de projetos e não vê o ramo com muito entusiasmo. O ocorrido com a Satyam Computer Services da Índia não o surpreendeu


Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
1   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03