Analisando as falhas de software

[jbcartoes]

Estamos sendo bombardeados - cada dia mais - com notícias sobre falhas descobertas neste ou naquele software, as quais permitem que hackers provoquem os mais variados incidentes de segurança. Mas, afinal, o que são estas falhas?
No capítulo 5 falamos sobre os problemas de se possuir um programa com falhas atualmente e quais as melhores maneiras para se certificar de que possuímos as devidas atualizações dos nossos sistemas. Agora vamos explicar como funcionam - ou "não funcionam" - estes mecanismos problemáticos.
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.