Estamos sendo bombardeados - cada dia mais - com notícias sobre falhas descobertas neste ou naquele software, as quais permitem que a gente "hackers" provocarem os mais variados incidentes de segurança. Mas, afinal, o que são estas falhas?

Quando profissionais da área de informática sentem uma inclinação para o ramo da programação, eles devem descobrir se possuem determinados vícios de raciocínio lógico imprescindíveis para a tarefa, e uma dessas qualificações é o exercício de "pensar o impensável", sempre fugir do padrão e analisar seriamente as exceções. Infelizmente nem todos dão o devido valor a isso.

A partir de agora vamos analisar um exemplo extremamente simplificado e descobrir porque administrar exceções é fundamental na segurança de um software.

Imagine uma rotina que verifique a senha de um usuário antes de liberar seu acesso a um sistema qualquer. Ela seria, a muito grosso modo, assim:

1ª instrução:


Pedir senha de 4 números ao usuário - usuário digita a senha.

2ª instrução:


Se os 4 números forem iguais à senha cadastrada, siga para 3ª instrução.
Se os 4 números forem diferentes, negar acesso. Fim do programa.

3ª instrução:


Liberar seu acesso. Fim do programa.

Esta é uma rotina simples que funciona muito bem, desde que o usuário obedeça a primeira instrução e digite sua senha de forma correta. Entretanto, é com relação a desobediência que se dá a importância de trabalhar com as exceções.

Vamos supor que o usuário não forneça os dados conforme o programa espera. Por exemplo, ao invés de números, ele digite 4 letras. Quando o programa chegar à 2ª instrução, o computador vai tentar colocar as letras em uma memória que está preparada para receber apenas números, e isto pode provocar um erro que invalidaria toda a 2ª instrução. Ao dar continuidade, o acesso estaria liberado na 3ª instrução independente da senha digitada, desde que não fossem 4 números.

O exemplo acima foi bem simplificado para facilitar o entendimento mas a idéia geral por trás das falhas de software é essa: rotinas mal projetadas que não prevêem todas as ações dos usuários (ou de outras partes do programa). Uma correção para o problema exposto seria uma alteração lógica na filosofia de comparação. Veja:

1ª instrução:


Pedir senha de 4 números ao usuário - usuário digita a senha.

2ª instrução:


Se os 4 números forem diferentes da senha cadastrada, siga para 3ª instrução.
Se os 4 números forem iguais, liberar acesso. Fim do programa.

3ª instrução:


Negar seu acesso. Fim do programa.

Com esta alteração, qualquer que fosse o erro provocado pela entrada incorreta de dados resultaria na negação do acesso, uma vez que um erro na 2ª instrução eliminaria a comparação juntamente com a decisão de liberar o acesso do usuário.

Obviamente, este tipo de problema não está limitado a situações de verificação de senhas, muito pelo contrário, ele se espalha pelas rotinas que não recebem muita atenção com relação à segurança, como por exemplo, rotinas de verificação de datas, classificação de dados e principalmente aquelas que recebem dados de outros programas.

Rotinas que são feitas para se comunicar - remotamente - com outras rotinas são as que apresentam as maiores falhas pois, ao construírem estes programas, não é levado em consideração que a rotina interlocutora pode ser modificada - ou substituída, por um hacker, talvez - e que, com isso, passar a enviar dados fora do padrão e do formato esperados, causando erros internos nos programas.

Estes erros provocados por ações despadronizadas e inesperadas nem sempre são tão inofensivos como o exemplo acima, fazendo com que o programa caia em uma falha pura e simples. Algumas vezes estes erros abrem uma brecha por onde podem ser inseridos comandos que o computador, desnorteado com a falha, assume ser parte do programa original e passa a seguir estas instruções implantadas.

O modo como estes comandos são implantados através das falhas é extremamente complexo do ponto de vista didático, principalmente em um curso básico sobre segurança, sendo um trabalho bastante árduo até mesmo para os maiores "escovadores de bits".

Portanto tenha em mente que, quando ouvir falar em uma falha de software que permite a invasão de um sistema ou interrupção de um serviço, você estará vendo o resultado de um trabalho que deveria ter sido feito na época da construção do programa, mas que ficou para depois, nas mãos de especialistas e de hackers.