9 tipos populares de ataque de injeção de aplicativos da Web

O problema com os aplicativos da Web é que eles são expostos abertamente a bilhões de usuários da Internet, muitos dos quais desejam violar suas medidas de segurança – por qualquer motivo.

Nos primórdios da Internet, um dos métodos de ataque mais comuns era a força bruta simples e básica. Esses ataques geralmente eram executados por bots – ou pessoas com bastante folga – que tentavam zilhões de combinações de nomes de usuário e senhas até encontrar uma que permitisse acesso ao aplicativo de destino.

Os ataques de força bruta não são mais uma ameaça, graças às políticas de senha, tentativas limitadas de login e captchas. Mas os cibercriminosos adoram descobrir novos exploits e usá-los para realizar novos tipos de ataques. Há muito tempo, eles descobriram que os campos de texto em aplicativos ou páginas da Web poderiam ser explorados inserindo – ou injetando – texto inesperado neles que forçaria o aplicativo a fazer algo que não deveria. Dessa forma, os chamados ataques de injeção entraram em cena.

Os ataques de injeção podem ser usados ​​não apenas para fazer login em um aplicativo sem saber o nome de usuário e a senha, mas também para expor informações privadas, confidenciais ou sensíveis, ou até mesmo para sequestrar um servidor inteiro. É por isso que esses ataques não são apenas uma ameaça aos aplicativos da Web, mas também aos usuários cujos dados residem nesses aplicativos e, no pior dos casos, a outros aplicativos e serviços conectados.

injeção de código

A injeção de código é um dos tipos mais comuns de ataques de injeção. Se os invasores conhecerem a linguagem de programação, a estrutura, o banco de dados ou o sistema operacional usado por um aplicativo da Web, eles poderão injetar código por meio de campos de entrada de texto para forçar o servidor da Web a fazer o que desejam.

Esses tipos de ataques de injeção são possíveis em aplicativos que não possuem validação de dados de entrada. Se um campo de entrada de texto permite que os usuários digitem o que quiserem, o aplicativo é potencialmente explorável. Para evitar esses ataques, o aplicativo precisa restringir o máximo possível as entradas que os usuários podem inserir.

Por exemplo, ele precisa limitar a quantidade de dados esperados, verificar o formato dos dados antes de aceitá-los e restringir o conjunto de caracteres permitidos.

As vulnerabilidades de injeção de código podem ser fáceis de encontrar, apenas testando a entrada de texto de um aplicativo da Web com diferentes tipos de conteúdo. Quando encontradas, as vulnerabilidades são moderadamente difíceis de explorar. Mas quando um invasor consegue explorar uma dessas vulnerabilidades, o impacto pode incluir perda de confidencialidade, integridade, disponibilidade ou funcionalidade do aplicativo.

injeção SQL

De maneira semelhante à injeção de código, esse ataque insere um script SQL – a linguagem usada pela maioria dos bancos de dados para realizar operações de consulta – em um campo de entrada de texto. O script é enviado para a aplicação, que o executa diretamente em seu banco de dados. Como resultado, o invasor pode passar por uma tela de login ou fazer coisas mais perigosas, como ler dados confidenciais diretamente do banco de dados, modificar ou destruir dados do banco de dados ou executar operações administrativas no banco de dados.

Os aplicativos PHP e ASP são propensos a ataques de injeção de SQL devido às suas interfaces funcionais mais antigas. Os aplicativos J2EE e ASP.Net geralmente são mais protegidos contra esses ataques. Quando uma vulnerabilidade de injeção de SQL é encontrada – e eles podem ser facilmente encontrados – a magnitude dos ataques potenciais será limitada apenas pela habilidade e imaginação do invasor. Assim, o impacto de um ataque de injeção de SQL é, sem dúvida, alto.

injeção de comando

Esses ataques também são possíveis, principalmente devido à validação de entrada insuficiente. Eles diferem dos ataques de injeção de código porque o invasor insere comandos do sistema em vez de trechos de código de programação ou scripts. Portanto, o hacker não precisa saber a linguagem de programação na qual o aplicativo está baseado ou a linguagem usada pelo banco de dados. Mas eles precisam conhecer o sistema operacional usado pelo servidor de hospedagem.

Os comandos do sistema inseridos são executados pelo sistema operacional host com os privilégios do aplicativo, o que pode permitir expor o conteúdo de arquivos arbitrários residentes no servidor, mostrar a estrutura de diretórios de um servidor, alterar senhas de usuários, entre outras coisas .

Esses ataques podem ser evitados por um administrador de sistema, limitando o nível de acesso ao sistema dos aplicativos da Web em execução em um servidor.

Script entre sites

Sempre que um aplicativo insere a entrada de um usuário na saída que ele gera, sem validá-lo ou codificá-lo, ele dá a oportunidade a um invasor de enviar um código malicioso para um usuário final diferente. Os ataques Cross-Site Scripting (XSS) aproveitam essas oportunidades para injetar scripts maliciosos em sites confiáveis, que são enviados para outros usuários do aplicativo, que se tornam vítimas do invasor.

O navegador das vítimas executará o script malicioso sem saber que não é confiável. Portanto, o navegador permitirá que ele acesse tokens de sessão, cookies ou informações confidenciais armazenadas pelo navegador. Se programados adequadamente, os scripts podem até reescrever o conteúdo de um arquivo HTML.

Os ataques XSS geralmente podem ser divididos em duas categorias diferentes: armazenados e refletidos.

Em ataques XSS armazenados, o script malicioso reside permanentemente no servidor de destino, em um fórum de mensagens, em um banco de dados, em um log de visitantes, etc. A vítima o obtém quando seu navegador solicita as informações armazenadas. Em ataques XSS refletidos, o script malicioso é refletido em uma resposta que inclui a entrada enviada ao servidor. Isso pode ser uma mensagem de erro ou um resultado de pesquisa, por exemplo.

Injeção XPath

Esse tipo de ataque é possível quando um aplicativo da Web usa informações fornecidas por um usuário para criar uma consulta XPath para dados XML. A maneira como esses ataques funcionam é semelhante à injeção de SQL: os invasores enviam informações malformadas para o aplicativo para descobrir como os dados XML estão estruturados e, em seguida, atacam novamente para acessar esses dados.

XPath é uma linguagem padrão com a qual, como SQL, você pode especificar os atributos que deseja encontrar. Para executar uma consulta em dados XML, os aplicativos da Web usam a entrada do usuário para definir um padrão ao qual os dados devem corresponder. Ao enviar uma entrada malformada, o padrão pode se transformar em uma operação que o invasor deseja aplicar aos dados.

Ao contrário do que acontece com o SQL, no XPath não existem versões diferentes. Isso significa que a injeção de XPath pode ser feita em qualquer aplicativo da Web que use dados XML, independentemente da implementação. Isso também significa que o ataque pode ser automatizado; portanto, ao contrário da injeção de SQL, ela tem o potencial de ser disparada contra um número arbitrário de objetivos.

Injeção de comando de email

Esse método de ataque pode ser usado para explorar servidores de e-mail e aplicativos que constroem instruções IMAP ou SMTP com entrada do usuário validada incorretamente. Ocasionalmente, os servidores IMAP e SMTP não têm proteção forte contra ataques, como seria o caso da maioria dos servidores da Web e, portanto, podem ser mais exploráveis. Entrando por um servidor de e-mail, os invasores podem escapar de restrições como captchas, um número limitado de solicitações etc.

Para explorar um servidor SMTP, os invasores precisam de uma conta de e-mail válida para enviar mensagens com comandos injetados. Se o servidor estiver vulnerável, ele responderá às solicitações dos invasores, permitindo que eles, por exemplo, revoguem as restrições do servidor e usem seus serviços para enviar spam.

A injeção de IMAP pode ser feita principalmente em aplicativos de webmail, explorando a funcionalidade de leitura de mensagens. Nesses casos, o ataque pode ser realizado simplesmente digitando, na barra de endereço de um navegador da web, uma URL com os comandos injetados.

injeção CRLF

A inserção de caracteres de retorno de carro e alimentação de linha – combinação conhecida como CRLF – em campos de entrada de formulários da web representa um método de ataque chamado injeção de CRLF. Esses caracteres invisíveis indicam o fim de uma linha ou o fim de um comando em muitos protocolos de internet tradicionais, como HTTP, MIME ou NNTP.

Por exemplo, a inserção de um CRLF em uma solicitação HTTP, seguida por algum código HTML específico, pode enviar páginas da Web personalizadas aos visitantes de um site.

Esse ataque pode ser executado em aplicativos da Web vulneráveis ​​que não aplicam a filtragem adequada à entrada do usuário. Essa vulnerabilidade abre a porta para outros tipos de ataques de injeção, como XSS e injeção de código, e também pode resultar em um site sendo sequestrado.

Injeção de cabeçalho do host

Em servidores que hospedam muitos sites ou aplicativos da web, o cabeçalho do host torna-se necessário para determinar qual dos sites ou aplicativos da web residentes – cada um deles conhecido como host virtual – deve processar uma solicitação recebida. O valor do cabeçalho informa ao servidor para qual dos hosts virtuais enviar uma solicitação. Quando o servidor recebe um cabeçalho de host inválido, ele geralmente o passa para o primeiro host virtual da lista. Isso constitui uma vulnerabilidade que os invasores podem usar para enviar cabeçalhos de host arbitrários ao primeiro host virtual em um servidor.

A manipulação do cabeçalho do host é comumente relacionada a aplicativos PHP, embora também possa ser feita com outras tecnologias de desenvolvimento web. Ataques de cabeçalho de host funcionam como facilitadores para outros tipos de ataques, como envenenamento de cache da web. Suas consequências podem incluir a execução de operações confidenciais pelos invasores, por exemplo, redefinições de senha.

Injeção de LDAP

O LDAP é um protocolo desenvolvido para facilitar a busca de recursos (dispositivos, arquivos, outros usuários) em uma rede. É muito útil para intranets e, quando usado como parte de um sistema de logon único, pode ser usado para armazenar nomes de usuários e senhas. As consultas LDAP envolvem o uso de caracteres de controle especiais que afetam seu controle. Os invasores podem alterar potencialmente o comportamento pretendido de uma consulta LDAP se puderem inserir caracteres de controle nela.

Novamente, a raiz do problema que permite ataques de injeção de LDAP é a entrada do usuário validada incorretamente. Se o texto que um usuário envia para um aplicativo for usado como parte de uma consulta LDAP sem sanitizá-lo, a consulta poderá recuperar uma lista de todos os usuários e mostrá-la a um invasor, apenas usando um asterisco

no lugar certo dentro de uma string de entrada.

Prevenção de ataques de injeção

Como vimos neste artigo, todos os ataques de injeção são direcionados a servidores e aplicações com acesso aberto a qualquer usuário da internet. A responsabilidade de prevenir esses ataques é distribuída entre os desenvolvedores de aplicativos e administradores de servidores.