A vulnerabilidade de aplicações web reside no seu acesso público a um vasto número de utilizadores da internet, alguns com intenções maliciosas que visam explorar as suas defesas de segurança.
Nos primórdios da internet, uma das táticas de ataque mais comuns era a de força bruta, um método simples que envolvia tentativas exaustivas de combinações de nomes de utilizador e palavras-passe, frequentemente executadas por bots ou indivíduos com tempo livre, até que uma combinação permitisse acesso à aplicação alvo.
Embora os ataques de força bruta já não sejam uma ameaça proeminente, devido a políticas de palavras-passe robustas, restrição de tentativas de login e o uso de captchas, os cibercriminosos procuram constantemente novas formas de explorar vulnerabilidades, originando novos tipos de ataques. Constataram que os campos de texto em páginas ou aplicações web podiam ser usados para inserir texto não esperado, forçando a aplicação a executar ações não previstas. Assim, surgiram os ataques de injeção.
Ataques de injeção não só podem ser usados para aceder a uma aplicação sem credenciais válidas, mas também para expor dados privados, confidenciais ou sensíveis, ou até comprometer um servidor inteiro. Por isso, esses ataques representam um perigo para aplicações web, mas também para os utilizadores e dados neles armazenados, e podem, em casos extremos, afetar outras aplicações e serviços conectados.
Injeção de Código
A injeção de código é uma das formas mais comuns de ataque de injeção. Ao conhecerem a linguagem de programação, estrutura, base de dados ou sistema operativo de uma aplicação web, atacantes podem injetar código através de campos de entrada de texto, obrigando o servidor a executar ações desejadas.
Estes ataques são viáveis em aplicações que não implementam validação de dados de entrada. Se um campo de texto aceita qualquer tipo de informação, a aplicação torna-se potencialmente explorável. Para mitigar estes riscos, a aplicação deve restringir ao máximo os dados que os utilizadores podem inserir.
Isso significa limitar a quantidade de dados esperados, verificar o formato dos dados antes de aceitá-los e restringir o conjunto de caracteres permitidos.
Vulnerabilidades de injeção de código são relativamente fáceis de detetar ao testar os campos de texto de aplicações web com diversos tipos de conteúdo. Apesar de serem moderadamente difíceis de explorar, uma vez que um atacante consiga ter sucesso, o impacto pode ser severo, incluindo a perda de confidencialidade, integridade, disponibilidade ou funcionalidade da aplicação.
Injeção SQL
De forma semelhante à injeção de código, este ataque envolve a inserção de um script SQL (a linguagem utilizada pela maioria das bases de dados para efetuar operações de consulta) num campo de texto. Este script é enviado para a aplicação, que o executa diretamente na sua base de dados. Desta forma, o invasor pode contornar o ecrã de login ou executar ações mais nefastas, como obter dados sensíveis diretamente da base de dados, modificar ou destruir dados, ou executar operações administrativas na base de dados.
Aplicações PHP e ASP são mais vulneráveis a ataques de injeção SQL, devido às suas interfaces mais antigas. Aplicações J2EE e ASP.Net tendem a ser mais resistentes a este tipo de ataque. Uma vez que uma vulnerabilidade de injeção SQL seja descoberta – o que não é difícil – o alcance potencial dos ataques é limitado apenas pela habilidade e imaginação do atacante. O impacto de um ataque de injeção SQL é, portanto, significativo.
Injeção de Comando
Estes ataques também ocorrem devido à validação inadequada dos dados de entrada. Diferem da injeção de código porque o atacante insere comandos do sistema operativo, em vez de código ou scripts de programação. Assim, o atacante não precisa de conhecer a linguagem de programação da aplicação ou da base de dados, apenas o sistema operativo do servidor.
Os comandos inseridos são executados pelo sistema operativo anfitrião com os mesmos privilégios da aplicação, permitindo expor o conteúdo de ficheiros, mostrar a estrutura de diretórios de um servidor, alterar palavras-passe de utilizadores, entre outras ações.
Estes ataques podem ser prevenidos limitando o nível de acesso ao sistema das aplicações web a funcionar num servidor.
Script Entre Sites (XSS)
Quando uma aplicação insere a entrada de um utilizador na saída que gera, sem a validar ou codificar, oferece a oportunidade a um atacante de enviar código malicioso a outro utilizador. Ataques de Cross-Site Scripting (XSS) exploram estas brechas para injetar scripts maliciosos em sites de confiança. Estes scripts são enviados a outros utilizadores da aplicação, que acabam por ser vítimas do ataque.
O navegador das vítimas executa o script malicioso sem ter conhecimento da sua natureza, permitindo que ele aceda a tokens de sessão, cookies ou informações sensíveis armazenadas no navegador. Scripts bem elaborados podem até reescrever o conteúdo de um ficheiro HTML.
Ataques XSS podem ser divididos em duas categorias principais: armazenados e refletidos.
Em ataques XSS armazenados, o script malicioso fica permanentemente guardado no servidor de destino, num fórum de mensagens, base de dados ou registo de visitantes. A vítima é exposta ao script ao solicitar a informação armazenada. Em ataques XSS refletidos, o script é refletido na resposta que inclui a entrada enviada ao servidor, como uma mensagem de erro ou resultado de uma pesquisa.
Injeção XPath
Este tipo de ataque ocorre quando uma aplicação web usa informação fornecida pelo utilizador para construir uma consulta XPath para dados XML. A forma como este ataque funciona é similar à injeção SQL: atacantes enviam informação malformada para a aplicação para descobrir como os dados XML estão estruturados e, posteriormente, atacam para aceder a esses dados.
XPath é uma linguagem padrão, similar ao SQL, que permite especificar os atributos que se procura encontrar. Para executar uma consulta em dados XML, as aplicações web usam a entrada do utilizador para definir um padrão que os dados devem corresponder. Ao enviar uma entrada malformada, o padrão pode transformar-se numa operação que o atacante pretende executar nos dados.
Ao contrário do SQL, não existem versões diferentes de XPath, o que significa que a injeção XPath pode ser realizada em qualquer aplicação web que utilize dados XML, independentemente da sua implementação. Este fato torna o ataque mais automatizável e, portanto, aplicável a um número arbitrário de alvos, ao contrário da injeção SQL.
Injeção de Comando de Email
Este método de ataque é usado para explorar servidores de email e aplicações que constroem instruções IMAP ou SMTP com entradas de utilizadores validadas de forma incorreta. Por vezes, servidores IMAP e SMTP têm proteções mais fracas contra ataques, o que os torna mais vulneráveis. Ao entrar por um servidor de email, atacantes podem contornar restrições como captchas ou um limite de pedidos.
Para explorar um servidor SMTP, atacantes precisam de uma conta de email válida para enviar mensagens com comandos injetados. Se o servidor for vulnerável, ele responderá às solicitações dos invasores, permitindo-lhes revogar restrições do servidor e usá-lo para enviar spam.
A injeção de IMAP pode ser feita principalmente em aplicações de webmail, explorando a funcionalidade de leitura de mensagens. Nestes casos, o ataque pode ser executado apenas ao digitar, na barra de endereço de um navegador web, um URL com os comandos injetados.
Injeção CRLF
A inserção de caracteres de retorno de carro e alimentação de linha (conhecidos como CRLF) em campos de entrada de formulários web representa um método de ataque chamado injeção CRLF. Estes caracteres invisíveis indicam o fim de uma linha ou o fim de um comando em diversos protocolos de internet tradicionais, como HTTP, MIME ou NNTP.
Por exemplo, a inserção de um CRLF numa solicitação HTTP, seguida por código HTML específico, pode direcionar páginas web personalizadas aos visitantes de um site.
Este ataque pode ser executado em aplicações web vulneráveis que não implementam uma filtragem adequada à entrada do utilizador, abrindo caminho para outros ataques, como XSS e injeção de código, e até mesmo resultando no sequestro de um site.
Injeção de Cabeçalho do Host
Em servidores que hospedam diversos sites ou aplicações web, o cabeçalho do host é essencial para determinar qual dos sites ou aplicações residentes deve processar a solicitação recebida. O valor do cabeçalho informa o servidor para qual dos hosts virtuais enviar a solicitação. Quando o servidor recebe um cabeçalho de host inválido, ele geralmente o encaminha para o primeiro host virtual da lista, uma vulnerabilidade que invasores podem explorar para enviar cabeçalhos arbitrários ao primeiro host virtual de um servidor.
A manipulação do cabeçalho do host está associada a aplicações PHP, embora possa ocorrer com outras tecnologias de desenvolvimento web. Ataques de cabeçalho de host funcionam como facilitadores de outros tipos de ataque, como envenenamento de cache web, podendo resultar na execução de operações sensíveis por parte dos atacantes, como redefinições de palavras-passe.
Injeção de LDAP
LDAP é um protocolo desenvolvido para facilitar a busca de recursos (dispositivos, ficheiros, outros utilizadores) numa rede. É útil para intranets e, quando usado como parte de um sistema de login único, pode ser utilizado para armazenar nomes de utilizadores e palavras-passe. Consultas LDAP envolvem o uso de caracteres de controlo especiais que afetam o seu controlo. Atacantes podem alterar o comportamento esperado de uma consulta LDAP ao inserir caracteres de controlo.
Mais uma vez, a raiz do problema que permite ataques de injeção LDAP é a validação inadequada da entrada do utilizador. Se o texto que um utilizador envia para uma aplicação for usado como parte de uma consulta LDAP sem ser tratado corretamente, a consulta pode recuperar uma lista de todos os utilizadores e mostrá-la a um atacante, apenas usando um asterisco no local certo dentro de uma string de entrada.
Prevenção de Ataques de Injeção
Como vimos, todos os ataques de injeção são direcionados a servidores e aplicações com acesso público na internet. A responsabilidade de prevenir estes ataques é partilhada entre os desenvolvedores de aplicações e os administradores de servidores.
Desenvolvedores de aplicações precisam de estar cientes dos riscos inerentes à validação incorreta de dados de entrada e devem implementar as melhores práticas para tratar corretamente a entrada do utilizador, reduzindo assim os riscos. Administradores de servidores devem auditar os seus sistemas regularmente para detetar vulnerabilidades e corrigi-las o mais rapidamente possível. Há diversas opções para realizar estas auditorias, seja por demanda ou automaticamente.