A6 Falhas de Injeção
Origem: OWASP Chapter Brasil, a enciclopédia livre.
Conteúdo |
A6.1 Descrição
As falhas de injeção permitem que um atacante insira código malicioso de uma aplicação web para outro sistema. Estes ataques incluem chamadas ao sistema operacional através de chamadas do sistema, o uso de programas externos através de comandos do interpretador (Shell), assim como chamadas a bancos de dados através de SQL (ex., injeção de SQL). Scripts completos escritos em perl, python e outras linguagens podem ser injetados e executados em aplicações web mal escritas. Sempre que uma aplicação web utiliza um interpretador de qualquer tipo há o perigo de um ataque de injeção.
Muitas aplicações web utilizam recursos do sistema operacional e programas externos para executar suas funções. O “Sendmail” é provavelmente o programa externo mais solicitado, mas muitos outros programas são utilizados da mesma forma. Quando uma aplicação web passa uma informação através de uma requisição http como parte de uma requisição externa, esta deve ser cuidadosamente tratada. Caso contrário, o atacante pode injetar caracteres especiais (meta caracteres), comandos maliciosos ou modificadores de comandos junto com a informação e a aplicação web irá passá-los ao sistema externo para execução.
Injeção de SQL é uma forma particularmente difundida e perigosa de injeção. Para explorar uma falha de injeção de SQL, o atacante precisa achar um parâmetro que a aplicação web passará ao banco de dados. Embutindo cuidadosamente comandos SQL maliciosos no conteúdo do parâmetro, o atacante pode enganar a aplicação web que irá encaminhar uma consulta maliciosa ao banco de dados. Estes ataques não tem um grau de dificuldade elevado e mais ferramentas tem surgido para encontrar essas falhas. As conseqüências são particularmente danosas, uma vez que um atacante pode obter, corromper ou destruir o conteúdo do banco de dados.
Ataques de injeção podem ser muito fáceis de descobrir e explorar, mas também podem ser extremamente obscuros. As conseqüências podem ter toda a gama de severidade, do trivial até o completo comprometimento ou destruição do sistema. Em qualquer caso, o uso de chamadas externas é bastante difundido e a probabilidade de uma aplicação web ter uma falha de injeção de comandos deve ser considerada alta.
A6.2 Ambientes afetados
Todo ambiente de aplicações web permite a execução de comandos externos como chamadas de sistema, comandos do interpretador (shell) e requisições SQL. A suscetibilidade de uma chamada externa a injeção de comandos depende como a chamada é feita e do componente específico que está sendo chamado, mas quase que a totalidade das chamadas externas podem ser atacadas se a aplicação web não estiver escrita apropriadamente.
A6.3 Exemplos e referências
- Exemplos: Um parâmetro malicioso pode modificar as ações de uma chamada de sistema que normalmente retornaria um arquivo do usuário corrente para retornar um outro arquivo (ex. incluindo “../” como parte da requisição do arquivo). Comandos adicionais podem ser adicionados no final de um parâmetro que é passado para um shell script para que este execute um interpretador (shell) adicional (ex. “rm –r *”. Consultas SQL podem ser modificadas adicionando elementos de “coação” na clausula “where” (ex. “OR 1=1”) para ganhar acesso ou modificar dados de forma não autorizada.
- OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: Data Validation http://www.owasp.org/documentation/guide.html
- How to Build an HTTP Request Validation Engine (J2EE validation with Stinger) http://www.owasp.org/columns/jeffwilliams/jeffwilliams2
- Have Your Cake and Eat it Too (.NET validation) http://www.owasp.org/columns/jpoteet/jpoteet2
- White Paper on SQL Injection: http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
A6.4 Como determinar se você está vulnerável
A melhor maneira de determinar se você está vulnerável a ataques de injeção de comandos é procurar por todas as chamadas de recursos externos no código fonte (ex. system, exec, fork, Runtime.exec, Consultas SQL ou qualquer coisa que a sintaxe seja para fazer requisições a interpretadores em seu ambiente). Note que muitas linguagens têm múltiplas maneiras de rodar comandos externos. Desenvolvedores devem rever seus códigos e procurar por todos os lugares onde a entrada de uma requisição HTTP possa ser o caminho para estas chamadas. Você deve examinar cuidadosamente cada uma dessas chamadas para se assegurar que os passos de proteção descritos abaixo estão sendo seguidos.
A6.5 Como se proteger
O modo mais simples para se proteger de injeções é evitar acessar interpretadores externos sempre que possível. Para muitos comandos de shell e algumas chamadas de sistema, há bibliotecas específicas que realizam as mesmas funções. A utilização destas bibliotecas não envolve o interpretador de comandos do sistema operacional e conseqüentemente evita um grande número de problemas com comandos de shell.
Para aquelas chamadas que você realmente necessita utilizar, como chamadas a bancos de dados, você deve validar cuidadosamente os dados para garantir que estes não contêm nenhum conteúdo malicioso. Você também pode estruturar diversas requisições de forma a assegurar que todos os parâmetros fornecidos são tratados como dados e não como conteúdo potencialmente executável. O uso de “stored procedures” ou “prepared statementes” irá prover proteção significante, assegurando que a entrada fornecida é tratada como dados. Estas medidas irão reduzir, mas não eliminar completamente, o risco envolvido nestas chamadas externas. Você ainda deve sempre validar estas entradas para ter certeza de que estas atendam as expectativas da aplicação em questão.
Outra forma de proteção forte contra injeção de comandos é se assegurar que a aplicação web roda somente com os privilégios que ela necessita absolutamente para executar suas funções. Dessa forma você não deve rodar o servidor web como “root” ou administrador ou acessar um banco de dados como “DBADMIN”, caso contrário um atacante pode abusar desses privilégios administrativos fornecidos a aplicação web. Alguns ambientes J2EE permitem o uso do Java sandbox, que pode prevenir a execução de comandos de sistema.
Se for necessária a utilização de um comando externo, qualquer informação que está sendo inserida no comando deve ser checada rigorosamente. Devem ser colocados mecanismos que manipulem quaisquer possíveis erros, timeouts ou bloqueios durante a chamada. Todas as saídas, códigos de retorno e códigos de erro vindos da chamada devem ser checados para assegurar que o processamento esperado realmente ocorreu. No mínimo, isto irá permitir que você determine que algo errado ocorreu. Caso contrário, o ataque pode acontecer e nunca ser detectado.
O OWASP Filters Project está produzindo componentes re-utilizáveis em diversas linguagens para ajudar a prevenir muitas formas de injeção. OWASP também lançou o CodeSeeker, um firewall de nível de aplicação.