Erros Relacionados com Defesas Permeáveis

A categoria de erros que tornam as defesas permeáveis ao nível do software está relacionada com técnicas defensivas que são frequentemente mal utilizadas, adulteradas, ou simplesmente ignoradas.

19. Controlo de acesso inadequado

Suponha que está a dar uma festa em sua casa para alguns amigos mais chegados e convidados desses amigos. Convida toda a gente para a sala de estar, mas enquanto conversa distraidamente com um dos seus amigos, um outro convidado vai ao seu frigorífico sem autorização, vasculha o armário onde guarda os seus medicamentos e vai bisbilhotar no seu quarto de dormir.

O software enfrenta problemas de autorização semelhantes, mas que podem ter consequências mais graves. Se não garantirmos que os utilizadores do nosso software só fazem aquilo que lhes é permitido fazer, os atacantes irão tentar explorar as autorizações inadequadas e experimentar funcionalidades não autorizadas que estavam destinadas apenas a utilizadores restritos.

20. Utilização de um algoritmo criptográfico quebrado ou inseguro

Se estivermos a lidar com dados sensíveis, ou precisarmos de proteger um canal de comunicação, é provável que utilizemos criptografia para nos protegermos contra potenciais atacantes. Podemos ser tentados a desenvolver o nosso próprio esquema de encriptação, procurando que o mesmo seja difícil de quebrar por atacantes.

No entanto, este tipo de criptografia ?caseira? é bem vista pelos atacantes. Na realidade, a criptografia é bastante difícil de desenvolver. Mesmo os matemáticos e cientistas informáticos mais brilhantes não conseguem uma garantia de segurança completa (e a vida deles é suplantar os esforços uns dos outros nesse sentido). Podemos pensar que acabámos de criar um algoritmo completamente novo que ninguém conseguirá quebrar, mas o mais provável é que tenhamos reinventado a roda e que esta nem consiga resistir ao primeiro ataque.

21. Palavra de passe hard-coded

É extremamente conveniente proceder ao hard-coding de uma conta e palavra de passe secretas no módulo de autenticação do nosso software. Esta prática pode reduzir os orçamentos de teste e de suporte, mas também pode reduzir a pó a segurança dos nossos clientes. Se a palavra de passe for a mesma em todo o nosso software, todos os clientes ficam vulneráveis se essa palavra de passe for desvendada.

Uma vez que se trata de hard-coding, normalmente os administradores de sistema terão grandes dificuldades em solucionar o problema. E todos sabemos como os administradores de sistemas gostam de inconveniências às tantas da madrugada, quando as suas redes estão a ser atacada. Neste conjunto de artigos sobre os 25 erros de programação mais perigosos, podemos dizer que todos eles podem ser explicados como erros honestos, mas os clientes do software que passam pelos problemas não verão as coisas da mesma forma.

22. Atribuição de permissões inseguras para recursos críticos

É rude pegar em algo sem antes pedir permissão, mas os utilizadores sem escrúpulos (ou seja, os atacantes) estão dispostos a gastar algum tempo para ver até onde podem ir. Se tivermos programas críticos, armazéns de dados, ou ficheiros de configuração com permissões que possibilitem a leitura e escrita de recursos por todo o mundo, isso acabará por acontecer mais cedo ou mais tarde. Apesar deste problema poder não ser considerado durante a implementação ou desenho, por vezes é nessas fases que a solução precisa de ser aplicada. Deixar esta questão para que um administrador de sistema atarefado se aperceba do problema e efectue as alterações adequadas, é um procedimento que fica muito aquém do óptimo ? e que é, por vezes, impossível.

23. Utilização insuficiente de valores aleatórios

Imagine um casino de Las Vegas em que os jogadores pudessem prever o próximo resultado do lançamento dos dados, o número da roleta, ou as cartas. Rapidamente teria que fechar as portas. Se utilizarmos funcionalidades de segurança que requerem uma grande aleatoriedade não a fornecermos, termos atacantes a dar gargalhadas de contentes. Podemos depender da aleatoriedade mesmo sem a conhecermos, como acontece aquando da geração de IDs de sessão ou de nomes de ficheiros temporários.

Os pseudo geradores de números aleatórios (ou PRNG - Pseudo-Random Number Generators) são muito utilizados, mas existem várias coisas que podem correr mal. Logo que um atacante consiga determinar qual o algoritmo que está a ser utilizado, poderá adivinhar o número aleatório seguinte com a frequência suficiente para lançar um ataque bem sucedido depois de um número relativamente pequeno de tentativas.

24. Execução com privilégios desnecessários

O conhecido super-herói Homem Aranha vive de acordo com a máxima que diz o seguinte: ?o grande poder implica grande responsabilidade?. O nosso software poderá precisar de privilégios especiais para realizar certas operações. No entanto, será extremamente arriscado utilizar esses privilégios durante mais tempo do que o estritamente necessário. Quando se está a correr o software com privilégios extra, a aplicação tem normalmente acesso a mais recursos do que aqueles que o utilizador imagina num dado momento.

Por exemplo, podemos lançar intencionalmente um programa separado e esse programa permitir que o seu utilizador especifique um ficheiro a abrir. Esta funcionalidade está frequentemente presente em utilitários de ajuda ou editores. O utilizador poderá então aceder a ficheiros não autorizados através do programa que foi lançado, graças aos privilégios extra. A execução de comandos pode acontecer de forma similar. Mesmo que não lancemos outros programas, as vulnerabilidades adicionais do nosso software poderão ter consequências mais sérias do que se estivéssemos a correr o programa com um nível mais baixo de privilégios.

25. Imposição no lado do cliente da segurança do lado do servidor

Os clientes com mais capacidades podem efectuar ataques mais elaborados, caso confiemos aos clientes a realização de verificações de segurança em representação do nosso servidor. Convém termos em conta que por baixo do GUI está apenas código. Os atacantes poderão proceder ao reverse engineering do nosso cliente e escrever os seus próprios clientes, deixando de lado certas funcionalidades inconvenientes, nomeadamente os controlos de segurança.

As consequências podem variar muito, dependendo daquilo que as nossas verificações de segurança estão a proteger. No entanto, alguns dos alvos mais comuns são a autenticação, autorização e validação de entradas. Se tivermos implementado segurança nos nossos servidores, precisamos de nos assegurar que não nos baseamos apenas nos clientes para impor essa segurança.

Baseado no relatório ?2009 CWE/SANS Top 25 Most Dangerous Programming Errors? de 12 de Janeiro de 2009.