9 tipos populares de ataque por injeção de aplicativo 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 quebrar suas medidas de segurança – sejam quais forem os motivos.


Nos primeiros dias da Internet, um dos métodos de ataque mais comuns era a força bruta simples e básica. Os bots geralmente realizavam esses ataques – ou pessoas com muito tempo de folga – que tentavam zilhões de combinações de nomes de usuário e senhas até encontrar um que permitisse o acesso ao aplicativo de destino..

Os ataques de força bruta não são mais uma ameaça, graças a políticas de senha, tentativas limitadas de login e captchas. Mas os cibercriminosos adoram descobrir novas explorações e usá-las para realizar novos tipos de ataques. Há muito tempo, eles descobriram que os campos de texto em aplicativos ou páginas da Web podiam ser explorados digitando -ou injetando- texto inesperado neles que forçariam 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 nome de usuário e senha, mas também para expor informações particulares, confidenciais ou confidenciais, ou mesmo para seqüestrar um servidor inteiro. É por isso que esses ataques não são apenas uma ameaça para aplicativos da Web, mas também para os usuários cujos dados residem nesses aplicativos e, nos piores casos, para 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 deseja.

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 permitir que os usuários insiram o que quiserem, o aplicativo é potencialmente explorável. Para evitar esses ataques, o aplicativo precisa restringir o máximo que os usuários de entrada têm permissão para entrar.

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 Web com diferentes tipos de conteúdo. Quando encontradas, as vulnerabilidades são moderadamente difíceis de explorar. Porém, 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 executar operações de consulta – em um campo de entrada de texto. O script é enviado ao aplicativo, 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 a 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 SQL é encontrada – e elas podem ser facilmente encontradas – a magnitude dos ataques em potencial será limitada apenas pela habilidade e imaginação do invasor. Assim, o impacto de um ataque de injeção SQL é indubitavelmente 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, pois o invasor insere comandos do sistema em vez de partes de códigos ou scripts de programação. Portanto, o hacker não precisa conhecer a linguagem de programação na qual o aplicativo se baseia 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 que residem no servidor, mostrar a estrutura de diretórios de um servidor, alterar as senhas dos usuários, entre outras coisas..

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

Script entre sites

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

O navegador das vítimas executará o script malicioso sem saber que não deve ser confiável. Portanto, o navegador permitirá acessar 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: armazenadas e refletidas.

No armazenado Nos ataques XSS, o script malicioso reside permanentemente no servidor de destino, em um fórum de mensagens, em um banco de dados, em um registro de visitantes, etc. A vítima recebe quando o navegador solicita as informações armazenadas. No refletido Ataques XSS, o script malicioso é refletido em uma resposta que inclui a entrada enviada ao servidor. 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 Web usa as informações fornecidas por um usuário para criar uma consulta XPath para dados XML. A maneira como esses ataques funcionam é semelhante à injeção SQL: os invasores enviam informações malformadas ao aplicativo para descobrir como os dados XML estão estruturados e depois atacam novamente para acessar esses dados..

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

Diferentemente do que acontece com o SQL, no XPath, não há versões diferentes. Isso significa que a injeção do 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, diferentemente da injeção SQL, ele pode ser disparado contra um número arbitrário de objetivos.

Injeção de comando de correio

Esse método de ataque pode ser usado para explorar servidores e aplicativos de email que criam 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 Web e, portanto, poderiam ser mais exploráveis. Ao entrar através de um servidor de correio, os invasores podem evitar restrições como captchas, um número limitado de solicitações, etc..

Para explorar um servidor SMTP, os invasores precisam de uma conta de email válida para enviar mensagens com comandos injetados. Se o servidor estiver vulnerável, ele responderá às solicitações dos invasores, permitindo que, por exemplo, substituam 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, um URL com os comandos injetados.

Injeção de CRLF

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

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

Esse ataque pode ser executado em aplicativos vulneráveis ​​da Web 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 invadido.

Injeção de cabeçalho de host

Em servidores que hospedam muitos sites ou aplicativos da Web, o cabeçalho do host torna-se necessário para determinar quais sites ou aplicativos da Web residentes – cada um deles conhecidos como host virtual – devem processar uma solicitação de entrada. 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, 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 para o 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 da web. Os ataques de cabeçalho de host funcionam como facilitadores para outros tipos de ataques, como envenenamento de cache da Web. Suas conseqüê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 pesquisa 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ário 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, o problema raiz que permite ataques de injeção 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 sanitá-la, a consulta poderá recuperar uma lista de todos os usuários e mostrá-la a um invasor, apenas usando um asterisco (*) à direita coloque dentro de uma sequência 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 aplicativos com acesso aberto a qualquer usuário da Internet. A responsabilidade de impedir esses ataques é distribuída entre desenvolvedores de aplicativos e administradores de servidores.

Os desenvolvedores de aplicativos precisam conhecer os riscos envolvidos na validação incorreta da entrada do usuário e aprender as melhores práticas para higienizar a entrada do usuário com a finalidade de prevenção de riscos. Os administradores de servidor precisam auditar seus sistemas periodicamente para detectar vulnerabilidades e corrigi-las o mais rápido possível. Existem muitas opções para realizar essas auditorias, sob demanda ou automaticamente.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map