Erros Relacionados com a Interacção Insegura Entre Componentes

Nesta categoria de erros estão incluídas falhas relacionadas com formas inseguras de envio e recepção de dados entre componentes, módulos, programas, threads, ou sistemas separados.

1. Validação imprópria de entradas

Segundo os responsáveis pelo relatório "2009 CWE/SANS Top 25 Most Dangerous Programming Errors", este é o erro que mais vitima o software. Os problemas surgem quando não é garantido que as entradas são conformes às expectativas. Por exemplo, um identificador que deva ser numérico de acordo com as expectativas, nunca poderá conter letras. O preço de um carro novo também nunca deverá admitir a quantia de um euro, apesar da crise económica actual!

Se não é programador, convém não esquecer que as aplicações têm normalmente requisitos de validação bem mais complexos do que estes dois exemplos simples. O que importa aqui é que a validação incorrecta de entradas pode conduzir a vulnerabilidades quando os atacantes conseguirem modificar as suas entradas de formas inesperadas. Muitas das vulnerabilidades actuais mais comuns podem ser eliminadas, ou pelo menos reduzidas através da utilização de uma validação adequada de entradas.

2. Codificação ou saída imprópria de resultados

Os computadores têm o estranho hábito de fazer aquilo que lhe mandamos fazer e não aquilo que queríamos que eles fizessem. Ou seja, mandamos fazer uma coisa, mas na realidade queríamos que fizessem outra. A codificação de resultados insuficiente conduz muitas vezes a uma fraca validação de resultados e pode abrir caminho a ataques. Um atacante pode modificar os comandos que um utilizador legítimo queria enviar a outros componentes, o que poderá provocar uma completa cooperação por parte da aplicação. Além disso, está-se a expor os outros componentes a utilizações que o atacante não conseguiria directamente. Isto provoca uma transformação da ordem dada - deixando de ser "faz aquilo que o utilizador legítimo quer" para passar a ser "faz aquilo que o atacante diz".

Quando um programa gera resultados (saídas) para outros componentes sob a forma de mensagens estruturadas - por exemplo, queries ou pedidos - precisa de separar a informação de controlo e os metadados dos dados reais. Mas isto é fácil de esquecer, dado que muitos paradigmas transportam dados e comandos juntos no mesmo fluxo, apenas com alguns caracteres especiais a delimitarem as fronteiras. Como exemplo podemos referir a Web 2.0 e outras frameworks cujo funcionamento esbate estas fronteiras, aumentando a exposição a ataques.

3. Falha em preservar a estrutura de query SQL

Actualmente, parece que o software só tem a ver com dados - colocação de dados na base de dados, recuperação de dados a partir da base de dados, transformação dos dados em informação, e envio dos dados para qualquer outro local. Se os atacantes conseguirem influenciar a SQL que utilizamos para comunicar com a nossa base de dados, poderão provocar grandes estragos.

Se utilizarmos queries SQL em controlos de segurança - como autenticação, por exemplo - os atacantes poderão alterar a lógica dessas queries para contornarem a segurança. Podem modificar as queries para roubar, corromper, ou alterar dados. Se for necessário, podem mesmo roubar um byte de cada vez, dado que têm a paciência e os conhecimentos necessários para fazer isso.

4. Falha em preservar a estrutura de página Web

O cross-site scripting (XSS) é uma das vulnerabilidades mais comuns, persistentes e perigosas que afectam as aplicações Web. É quase inevitável quando se combina a natureza do HTTP, a mistura de dados e de script no HTML, uma grande quantidade de dados a passar entre sites Web, vários esquemas de codificação e browsers ricos em termos de funcionalidades. Se não tivermos cuidado, os atacantes podem injectar Javascript ou outro conteúdo executável numa página Web gerada pela nossa aplicação.

A nossa página Web é então acedida por outros utilizadores, cujos browsers executam o script malicioso como se viesse do utilizador legítimo (algo que aconteceu na realidade). De repente, o nosso site Web está a servir código que nós não escrevemos. Os atacantes podem utilizar várias técnicas para intervirem directamente no nosso servidor.

5. Falha em preservar a estrutura de comando OS

O nosso software é frequentemente a ponte entre o exterior da rede e o interior do nosso sistema operativo. Quando invocamos outro programa no sistema operativo e permitimos entradas (que possam não ser de confiança) na sequência de comando que geramos para executar esse programa, estamos a convidar os atacantes a passarem a ponte e a executarem os seus próprios comandos em vez dos nossos.

6. Transmissão de informação sensível sob a forma de texto perceptível

Se o nosso software enviar informação sensível através de uma rede - por exemplo, dados privados ou credenciais de autenticação - essa informação vai passar por diferentes nós até chegar ao destino. Os atacantes podem aceder a esses dados através da rede sem grande esforço. Precisam apenas de controlar um qualquer nó ao longo do caminho, ou ligar-se a uma interface disponível. A tentativa de ofuscar o tráfego através da utilização de esquemas como o Base64 e a codificação URL não representa qualquer protecção. Estas codificações destinam-se à normalização das comunicações e não à mistura de dados para os tornar ilegíveis.

7. Imitação de pedidos entre sites (ou CSRF)

Todos sabemos que não se deve aceitar nenhum embrulho ou bagagem de estranhos no aeroporto, uma vez que o conteúdo pode ser perigoso. Se alguma coisa correr mal, somos nós os responsáveis, porque éramos nós os transportadores do embrulho à entrada para o avião, ou a bagagem consta no nosso check-in. A imitação de pedidos entre sites - ou Cross-Site Request Forgery (CSRF) - é como um desses estranhos embrulhos ou bagagem. A diferença neste caso é que o atacante procura levar um utilizador legítimo a activar um pedido que vai para o nosso site. Graças ao scripting e à forma geral de funcionamento da Web, o utilizador até pode não ter consciência de que está a enviar o pedido.

Quando o pedido chega ao servidor, parece ser oriundo do utilizador legítimo e não do atacante. Isto pode não parecer muito relevante, mas a verdade é que o atacante se mascarou de utilizador legítimo e conseguiu todo o acesso potencial concedido ao utilizador legítimo. Isto é especialmente útil quando o utilizador legítimo tem privilégios de administrador, podendo assim ficar comprometida toda a funcionalidade da aplicação. Quando combinada com o XSS, o resultado pode ser devastador.

8. Situação de concorrência

Os acidentes de tráfego ocorrem quando dois veúculos tentam utilizar o mesmo recurso ao mesmo tempo. Ou seja, quando tentam utilizar a mesma parte da estrada. As situações de concorrência no nosso software não são muito diferentes, excepto no facto de um atacante procurar explorá-las de forma consciente para causar o caos ou para fazer com que a nossa aplicação lhe forneça algo valioso. Em muitos casos, uma situação de concorrência pode envolver múltiplos processos, com o atacante a ter o controlo total de um processo.

Mesmo quando a situação de concorrência ocorre entre múltiplos threads, o atacante pode ser capaz de influenciar quando alguns desses threads são executados. Nestas situações de concorrência, a corrupção de dados e a negação de serviço são a norma. O impacto destes ataques pode ser local ou global, dependendo daquilo que é afectado pela situação de concorrência - por exemplo, variáveis de estado ou lógica de segurança - e se ocorre dentro de múltiplos threads, processos, ou sistemas.

9. Fuga de informação de mensagem de erro

Se utilizarmos mensagens de erro muito informativas, estas podem desvendar segredos a qualquer atacante que utilize o nosso software de forma abusiva. Os segredos podem abarcar um leque alargado de dados valiosos, incluindo informação identificável pessoalmente (PII - Personally Identifiable Information), credenciais de autenticação e configuração do servidor.

Por vezes, podemos pensar que se trata de segredos inofensivos que são convenientes para os utilizadores e administradores legítimos - por exemplo, o caminho completo de instalação do software. No entanto, mesmo estes pequenos segredos podem simplificar muito um ataque concertado. Esta é uma preocupação a ter em conta, independentemente de se enviarem mensagens de erro temporárias para os utilizadores legítimo, ou de se registarem de forma permanente num ficheiro log.

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