2.1 CVE-2011-4132

Este padrão de ataque envolve causar um buffer overflow através da manipulação das variáveis do ambiente. Quando o adversário descobre que pode modificar uma variável de ambiente, ele pode tentar transbordar os buffers associados. Este ataque alavanca a confiança implícita muitas vezes colocada nas variáveis de ambiente. Identificar aplicação alvo] O adversário identifica uma aplicação ou programa alvo para realizar o estouro de buffer. Neste ataque o adversário procura por uma aplicação que carrega o conteúdo de uma variável de ambiente em um buffer. O adversário identifica um vetor de injeção para entregar o conteúdo excessivo ao buffer da aplicação alvo. O adversário prepara o conteúdo a ser injetado. Se a intenção é simplesmente causar o travamento do software, o conteúdo só precisa consistir em uma quantidade excessiva de dados aleatórios. Se a intenção é alavancar o overflow para a execução de código arbitrário, o adversário prepara a carga de tal forma que o endereço de retorno sobrescrito é substituído por um dos escolhidos pelo adversário. Usando o vetor de injeção, o adversário injeta o conteúdo do transbordamento no buffer.

Um atacante pode usar Server Side Include (SSI) Injection para enviar código para uma aplicação web que depois é executada pelo servidor web. Fazendo isso, o atacante pode alcançar resultados similares ao Cross Site Scripting, ou seja, execução arbitrária de código e divulgação de informações, embora em uma escala mais limitada, já que as diretivas SSI não são tão poderosas quanto uma linguagem de script completa. No entanto, o atacante pode convenientemente obter acesso a arquivos sensíveis, tais como arquivos de senha, e executar comandos shell. O adversário determina se o lado do servidor inclui está habilitado no servidor web alvo. Procure por entrada controlável pelo usuário, incluindo cabeçalhos HTTP, que podem levar diretivas do lado do servidor para o servidor web. Usando o ponto de injeção encontrado, o adversário envia um código arbitrário para ser incluído pela aplicação no lado do servidor. Eles podem então precisar visualizar uma página específica para que o servidor execute a diretiva include e execute um comando ou abra um arquivo em nome do adversário.

Um atacante é capaz de fazer com que uma vítima carregue conteúdo em seu navegador da Web que ultrapasse os controles da zona de segurança e ganhe acesso a privilégios maiores para executar código de script ou outros objetos da Web, como controles ActiveX ou applets não assinados. Este é um ataque de elevação de privilégios direcionado à segurança do navegador da Web baseado em zonas. Encontrar sistemas susceptíveis ao ataque] Encontrar sistemas que contenham funcionalidades que sejam acessadas tanto da zona de Internet como da zona local. Tem de haver uma forma de fornecer entrada para essa funcionalidade a partir da zona de Internet e essa entrada original tem de ser usada posteriormente numa página a partir de uma zona local. O atacante precisa primeiro encontrar alguma funcionalidade do sistema ou possivelmente outra fraqueza no sistema (por exemplo, susceptibilidade de cross site scripting) que forneça ao atacante um mecanismo para entregar a carga útil (ou seja, o código a ser executado) para o usuário. O local a partir do qual este código é executado no navegador do usuário precisa estar dentro da zona da máquina local. Desenvolver a carga a ser executada na zona superior privilegiada do navegador do usuário. Injetar a carga útil e tentar atrair a vítima (se possível) para a execução da funcionalidade que liberta a carga útil.

Um atacante usa métodos de injeção SQL padrão para injetar dados na linha de comando para execução. Isto poderia ser feito diretamente através do uso indevido de diretivas como MSSQL_xp_cmdshell ou indiretamente através da injeção de dados no banco de dados que seriam interpretados como comandos shell. Algum tempo depois, uma aplicação backend inescrupulosa (ou poderia fazer parte da funcionalidade da mesma aplicação) vai buscar os dados injetados armazenados no banco de dados e usa esses dados como argumentos de linha de comando sem realizar a validação apropriada. Os dados maliciosos escapam desse plano de dados através da geração de novos comandos a serem executados no host. O atacante injeta a sintaxe SQL nas entradas de dados controláveis pelo usuário para pesquisar a execução não filtrada da sintaxe SQL em uma consulta. Atingir execução arbitrária de comandos através de SQL Injection com a diretiva MSSQL_xp_cmdshell] O atacante alavanca um ataque de SQL Injection para injetar código shell a ser executado alavancando a diretiva xp_cmdshell. Injectar dados maliciosos no banco de dados] Alavanca a injeção de SQL para injetar dados no banco de dados que poderiam mais tarde ser usados para obter injeção de comandos se alguma vez usados como argumento de linha de comando [Acionar execução em linha de comando com argumentos injetados] O atacante causa a execução da funcionalidade de linha de comando que alavanca o conteúdo do banco de dados injetado anteriormente como argumento.

Um atacante aproveita uma fraqueza presente no código da camada de acesso ao banco de dados gerado com uma ferramenta de Mapeamento Relacional a Objetos (ORM) ou uma fraqueza na forma como um desenvolvedor usou um framework de persistência para injetar seus próprios comandos SQL a serem executados contra o banco de dados subjacente. O ataque aqui é semelhante à injeção SQL simples, exceto que a aplicação não usa JDBC para falar diretamente com o banco de dados, mas em vez disso usa uma camada de acesso a dados gerada por uma ferramenta ORM ou framework (por exemplo, Hibernate). Enquanto na maioria das vezes o código gerado por uma ferramenta ORM contém métodos de acesso seguros que são imunes à injeção SQL, algumas vezes devido a alguma fraqueza no código gerado ou devido ao fato do desenvolvedor não ter usado os métodos de acesso gerados corretamente, a injeção SQL ainda é possível. Determine Persistence Framework Used] Um atacante tenta determinar qual framework de persistência é usado pelo aplicativo a fim de aproveitar um ponto fraco no código da camada de acesso aos dados gerados ou um ponto fraco de uma forma que a camada de acesso aos dados possa ter sido usada pelo desenvolvedor. O atacante injeta a sintaxe ORM nas entradas de dados controláveis pelo usuário da aplicação para determinar se é possível modificar a estrutura e o conteúdo da consulta de dados. Executar SQL Injection através da camada de acesso aos dados gerados] Um atacante procede para explorar uma fraqueza nos métodos de acesso aos dados gerados que não separa corretamente o plano de controle do plano de dados, ou potencialmente uma forma particular na qual o desenvolvedor pode ter usado mal o código gerado, para modificar a estrutura das consultas SQL executadas e/ou injetar consultas SQL inteiramente novas.

Um atacante modifica os parâmetros da mensagem SOAP que é enviada pelo consumidor do serviço para o provedor de serviços para iniciar um ataque de injeção SQL. No lado do provedor de serviços, a mensagem SOAP é analisada e os parâmetros não são devidamente validados antes de serem utilizados para acessar um banco de dados de uma forma que não utilize a ligação de parâmetros, permitindo assim que o atacante controle a estrutura da consulta SQL executada. Este padrão descreve um ataque de injeção SQL com o mecanismo de entrega sendo uma mensagem SOAP. Detectar Manuseio Incorreto de Parâmetros SOAP] O atacante ataca com os parâmetros da mensagem SOAP e procura indicações de que a adulteração causou uma mudança no comportamento da aplicação alvo. O atacante injeta a sintaxe SQL em parâmetros SOAP vulneráveis identificados durante a fase de Exploração para procurar por execução não filtrada da sintaxe SQL em uma consulta. O atacante injeta SQL via parâmetros SOAP identificados como vulneráveis durante a fase Explorar para lançar um ataque de injeção SQL de primeira ou segunda ordem.

O adversário utiliza a repetição do processo de codificação de um conjunto de caracteres (ou seja, a codificação de um caractere) para ofuscar a carga útil de um determinado pedido. Isso pode permitir que o adversário contorne filtros que tentam detectar caracteres ou cordas ilegais, como os que podem ser usados em ataques de travessia ou injeção. Os filtros podem ser capazes de capturar cadeias de caracteres codificadas ilegalmente, mas não podem capturar cadeias de caracteres duplamente codificadas. Por exemplo, um ponto (.), frequentemente utilizado em ataques de travessias de caminho e, portanto, muitas vezes bloqueado por filtros, pode ser codificado URL como %2E. No entanto, muitos filtros reconhecem essa codificação e ainda assim bloqueiam o pedido. Em uma codificação dupla, a % na codificação de URL acima seria codificada novamente como %25, resultando em %252E que alguns filtros poderiam não capturar, mas que ainda assim poderia ser interpretado como um ponto (.) por intérpretes no alvo. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um atacante registra todos os pontos de entrada na aplicação. Tente codificação dupla para partes do input, a fim de tentar passar pelos filtros. Por exemplo, ao codificar duplamente certos caracteres na URL (por exemplo, pontos e cortes) um adversário pode tentar obter acesso a recursos restritos no servidor web ou forçar a navegação para páginas protegidas (subvertendo assim o serviço de autorização). Um adversário também pode tentar outros ataques ao estilo de injeção usando este padrão de ataque: injeção de comandos, injeção SQL, etc.

O adversário modifica direta ou indiretamente as variáveis de ambiente utilizadas pelo software alvo ou controlando-o. O objetivo do adversário é fazer com que o software alvo se desvie do seu funcionamento esperado de uma forma que beneficie o adversário. O adversário primeiro sonda a aplicação alvo para determinar informações importantes sobre o alvo. Esta informação pode incluir os tipos de software utilizados, versões de software, o que o utilizador consome, etc. Mais importante, o adversário tenta determinar quais variáveis de ambiente podem ser usadas pelo software subjacente, ou mesmo pela própria aplicação. Usando a informação encontrada ao sondar a aplicação, o adversário tenta manipular qualquer variável de ambiente controlada pelo usuário que tenha encontrado, ou suspeita de estar sendo usada pela aplicação, e observar os efeitos dessas mudanças. Se o adversário notar alguma alteração significativa na aplicação, saberá que uma determinada variável de ambiente é importante para o comportamento da aplicação e indica um possível vetor de ataque. O adversário manipula a(s) variável(s) de ambiente encontrada(s) para abusar do fluxo normal dos processos ou para obter acesso a recursos privilegiados.

Um adversário inclui a formatação de caracteres em um campo de entrada de string na aplicação de destino. A maioria das aplicações assume que os usuários fornecerão texto estático e podem responder de forma imprevisível à presença de caracteres de formatação. Por exemplo, em certas funções das linguagens de programação C, como impressão, o caractere de formatação %s imprimirá o conteúdo de um local de memória que espera que esse local identifique uma string e o caractere de formatação %n imprimirá o número de DWORD escritos na memória. Um adversário pode usar isto para ler ou escrever em locais ou ficheiros da memória, ou simplesmente para manipular o valor do texto resultante de formas inesperadas. A leitura ou gravação na memória pode resultar em falhas no programa e a gravação na memória pode resultar na execução de código arbitrário se o adversário puder gravar na pilha do programa. Aplicação de pesquisa] O adversário faz um inventário dos pontos de entrada da aplicação. Determinar a entrada controlável pelo usuário susceptível à injeção de formatação de string] Determinar a entrada controlável pelo usuário susceptível à injeção de formatação de string. Para cada entrada controlável pelo usuário que o adversário suspeita ser vulnerável à injeção de formatação de string, tente injetar caracteres de formatação, tais como %n, %s, etc. O objetivo é manipular a criação da string usando esses caracteres de formatação. Depois de determinar que um dado input é vulnerável à injeção de formatação de string, faça uma hipótese de como o uso subjacente é e as restrições associadas.

Um atacante manipula ou faz uma consulta LDAP com o propósito de minar a segurança do alvo. Algumas aplicações utilizam a entrada do usuário para criar consultas LDAP que são processadas por um servidor LDAP. Por exemplo, um usuário pode fornecer seu nome de usuário durante a autenticação e o nome de usuário pode ser inserido em uma consulta de LDAP durante o processo de autenticação. Um atacante pode usar essa entrada para injetar comandos adicionais em uma consulta de LDAP que pode revelar informações confidenciais. Por exemplo, a inserção de um * na consulta acima mencionada pode retornar informações sobre todos os usuários no sistema. Este ataque é muito semelhante a um ataque de injeção SQL na medida em que manipula uma consulta para reunir informações adicionais ou coagir um determinado valor de retorno. O atacante faz um inventário dos pontos de entrada da aplicação. Para cada entrada controlável pelo usuário que o atacante suspeita ser vulnerável à injeção de LDAP, tente injetar caracteres que tenham um significado especial em LDAP (como um único caractere de citação, etc.). O objetivo é criar uma consulta de LDAP com uma sintaxe inválida [Tente explorar a vulnerabilidade da injeção de LDAP] Após determinar que um dado input é vulnerável à injeção de LDAP, faça uma hipótese de como a consulta subjacente se parece. Possivelmente usando uma ferramenta, tente iterativamente adicionar lógica à consulta para extrair informações do LDAP, ou para modificar ou apagar informações no LDAP.

Este tipo de ataque explora uma vulnerabilidade de buffer overflow em software cliente alvo através da injeção de conteúdo malicioso a partir de um serviço hostil personalizado. Este serviço hostil é criado para fornecer o conteúdo correto ao software cliente. Por exemplo, se o aplicativo do lado do cliente for um navegador, o serviço hospedará uma página da Web que o navegador carrega. O adversário identifica um aplicativo do lado do cliente de destino para executar o buffer overflow on. Os mais comuns são os navegadores. Se houver uma vulnerabilidade conhecida do navegador, o adversário pode ser o alvo. O adversário identifica um vetor de injeção para entregar o conteúdo excessivo ao buffer da aplicação alvo. [Criar serviço hostil] O adversário cria um serviço hostil que irá entregar o conteúdo para a aplicação do lado do cliente. Se a intenção é simplesmente causar o travamento do software, o conteúdo só precisa consistir em uma quantidade excessiva de dados aleatórios. Se a intenção é aproveitar o transbordamento para execução de código arbitrário, o adversário elabora a carga de tal forma que o endereço de retorno sobrescrito é substituído por um dos escolhidos pelo adversário. Usando o vetor de injeção, o adversário entrega o conteúdo à aplicação do lado do cliente usando o serviço hostil e transborda o buffer.

Um atacante explora um ponto fraco na validação de entrada controlando o formato, estrutura e composição dos dados para uma interface de processamento de entrada. Ao fornecer a entrada de uma forma não padrão ou inesperada, um atacante pode ter um impacto adverso na segurança do alvo.

Um atacante engana uma vítima para executar conteúdo flash malicioso que executa comandos ou faz chamadas flash especificadas pelo atacante. Um exemplo deste ataque é o flashing cruzado, um parâmetro controlado por um atacante para uma chamada de referência carregada a partir de um conteúdo especificado pelo atacante. O atacante primeiro faz um inventário dos pontos de entrada da aplicação. Determinar a susceptibilidade da aplicação à injeção de Flash] Determinar a susceptibilidade da aplicação à injeção de Flash. Para cada URL identificado na fase de exploração, o atacante tenta usar várias técnicas, como asfunção de carga direta, página/hospedeiro mal controlado, injeção de Flash HTML e injeção DOM para determinar se a aplicação é suscetível à injeção de Flash. Injetar conteúdo malicioso no alvo] Injetar conteúdo malicioso no alvo utilizando vetores de injeção vulneráveis identificados na fase Experimentar

Um adversário cria um arquivo com conteúdo de script, mas onde o tipo MIME especificado do arquivo é tal que o script não é esperado. O adversário engana a vítima para acessar um URL que responde com o arquivo de script. Alguns navegadores detectarão que o tipo MIME especificado do ficheiro não corresponde ao tipo real do seu conteúdo e mudarão automaticamente para o tipo de conteúdo real utilizando um intérprete. Se o navegador não invocar filtros de script antes de fazer isso, o script do adversário pode ser executado no alvo não digitalizado, possivelmente revelando os cookies da vítima ou executando script arbitrário em seu navegador. Usando um navegador ou uma ferramenta automatizada, um adversário segue todos os links e ações públicas em um site da Web. Eles registram todas as áreas que permitem que um usuário carregue conteúdo através de uma solicitação HTTP POST. Isto é normalmente encontrado em blogs ou fóruns. O adversário usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e faz upload de arquivos com conteúdo de script, mas cujo tipo MIME é especificado como um tipo de arquivo que não pode executar conteúdo de script. Se o aplicativo verificar apenas o tipo MIME do arquivo, ele pode deixar o arquivo passar, fazendo com que o script seja executado por qualquer usuário que acesse o arquivo. Uma vez que o adversário tenha determinado quais locais de carregamento de arquivo são vulneráveis ao descasamento do tipo MIME, ele carregará um script malicioso disfarçado como um arquivo não scripting. O adversário pode ter muitos objetivos, desde roubar IDs de sessão, cookies, credenciais e conteúdo de página de uma vítima. Para que o ataque seja bem-sucedido, a vítima precisa visualizar o conteúdo malicioso armazenado na página da web.

Um ataque deste tipo explora vulnerabilidades na autenticação do canal de comunicação cliente / servidor e integridade de dados. Ele alavanca a confiança implícita que um servidor deposita no cliente, ou mais importante, aquela que o servidor acredita ser o cliente. Um invasor executa esse tipo de ataque comunicando-se diretamente com o servidor onde o servidor acredita estar se comunicando apenas com um cliente válido. Existem inúmeras variações desse tipo de ataque.

Um adversário envenena arquivos com uma carga útil maliciosa (visando os sistemas de arquivos acessíveis pelo software alvo), que podem ser passados por canais padrão, como por e-mail, e conteúdo padrão da web, como arquivos PDF e multimídia. O adversário explora vulnerabilidades conhecidas ou rotinas de manuseio nos processos alvo, a fim de explorar a confiança do host na execução de conteúdo remoto, incluindo arquivos binários.

As aplicações muitas vezes precisam transformar dados dentro e fora de um formato de dados (por exemplo, XML e YAML) usando um analisador. Pode ser possível para um adversário injetar dados que podem ter um efeito adverso sobre o analisador quando este está sendo processado. Muitas linguagens de formato de dados permitem a definição de estruturas do tipo macro que podem ser usadas para simplificar a criação de estruturas complexas. Ao aninhar essas estruturas, fazendo com que os dados sejam repetidamente substituídos, um adversário pode fazer com que o analisador consuma mais recursos durante o processamento, causando consumo excessivo de memória e utilização da CPU. Um adversário determina o fluxo de dados de entrada que está sendo processado por um analisador de dados que suporta o uso de substituição do lado da vítima. Um adversário processa dados de entrada que podem ter um efeito adverso no funcionamento do analisador quando os dados são analisados no sistema da vítima.

Um adversário injecta cargas úteis de dados seriados sobredimensionados num analisador durante o processamento de dados para produzir efeitos adversos sobre o analisador, tais como esgotamento dos recursos do sistema e execução arbitrária do código. Um adversário determina o fluxo de dados de entrada que está a ser processado por um analisador de dados serializado do lado da vítima. Um adversário introduz dados que podem ter um efeito adverso sobre o funcionamento do analisador de dados quando os dados são analisados no sistema da vítima.

Neste ataque, a ideia é fazer com que um filtro activo falhe, causando uma transacção demasiado grande. Um atacante pode tentar alimentar o programa com cadeias de entrada muito longas, numa tentativa de sobrecarregar o filtro (causando um buffer overflow) e esperando que o filtro não falhe com segurança (ou seja, a entrada do usuário é deixada no sistema sem filtragem). O atacante faz um levantamento da aplicação alvo, possivelmente como um usuário válido e autenticado [Tentativas de injeção] Tenta alimentar o sistema com dados excessivamente longos. Isto pode ser feito manualmente ou uma ferramenta dinâmica (caixa preta) pode ser usada para automatizar isto. Um atacante também pode usar um script personalizado para esse fim. [Monitorar respostas] Preste atenção a qualquer indicação de falha que ocorra. Observe cuidadosamente para ver o que aconteceu quando a falha no filtro ocorreu. Os dados entraram? Um atacante escreve um script para induzir a falha no filtro de forma consistente.

Um atacante utiliza dados XML criados pelo usuário para sondar, atacar e injetar dados na base de dados XML, usando técnicas similares à injeção SQL. A entrada controlável pelo usuário pode permitir a visualização não autorizada de dados, contornando a autenticação ou a aplicação front-end para acesso direto ao banco de dados XML, e possivelmente alterando a informação do banco de dados. Usando um navegador ou uma ferramenta automatizada, um adversário registra todas as instâncias de entrada controlável pelo usuário usadas para contruir consultas XML [Determinar a Estrutura das Consultas] Usando meios manuais ou automatizados, testar as entradas encontradas para os pontos fracos de XML. Inject Content into XML Queries] Crie conteúdo malicioso contendo expressões XML que não é validado pela aplicação e é executado como parte das consultas XML.

Um adversário que está autorizado a enviar consultas a um alvo envia variantes de consultas esperadas na esperança de que essas consultas modificadas possam retornar informações (direta ou indiretamente através de logs de erros) além do que o conjunto esperado de consultas deve fornecer. O adversário que está autorizado a enviar consultas a um alvo envia variantes de consultas esperadas na esperança de que essas consultas modificadas possam retornar informações (direta ou indiretamente através de logs de erros) além do que o conjunto esperado de consultas deve fornecer. Gerar inputs fuzzed] Dada uma ferramenta fuzzing, um input ou protocolo alvo e limites de tempo, complexidade e variedade de inputs, gere uma lista de inputs para tentar. Embora o fuzzing seja aleatório, ele não é exaustivo. Parâmetros como comprimento, composição e quantas variações a tentar são importantes para obter o impacto mais econômico do fuzzer. Observe os outputs para os inputs alimentados no sistema pelos fuzzers e veja se há algum log ou mensagens de erro que forneçam dados sensíveis ou informações sobre um modelo esperado que possa ser usado para produzir esses dados. [Craft exploit payloads] Se os logs não revelarem nenhum dado sensível ao usuário/usuário, um adversário tentará fazer o formulário de entradas do fuzzing para um template esperado

Um adversário aproveita a possibilidade de codificar entradas ou conteúdos potencialmente nocivos utilizados por aplicações de tal forma que as aplicações são ineficazes para validar este padrão de codificação. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todos os pontos de entrada da aplicação. O adversário usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injeta várias cargas úteis usando uma variedade de tipos diferentes de codificação para determinar se um ponto de entrada realmente representa uma vulnerabilidade com lógica de validação insuficiente e para caracterizar até que ponto a vulnerabilidade pode ser explorada.

Neste padrão de ataque, o adversário alavanca o zumbido para tentar identificar fraquezas no sistema. O fuzzing é um método de teste de segurança e funcionalidade de software que alimenta o sistema com inputs construídos aleatoriamente e procura uma indicação de que ocorreu uma falha em resposta a esse input. O fuzzing trata o sistema como uma caixa preta e é totalmente livre de quaisquer preconceitos ou suposições sobre o sistema. O Fuzzing pode ajudar um atacante a descobrir certas suposições feitas sobre o input do usuário no sistema. O Fuzzing dá a um atacante uma forma rápida de potencialmente descobrir algumas dessas suposições apesar de não saber necessariamente nada sobre os internos do sistema. Estas suposições podem então ser viradas contra o sistema através da criação especial de informações do usuário que podem permitir a um atacante atingir seus objetivos. [Observar comunicação e entradas] O atacante que ataca o fuzzing observa o sistema alvo procurando por entradas e comunicações entre módulos, subsistemas ou sistemas. Gerar entradas de fuzzing] Dada uma ferramenta de fuzzing, uma entrada de alvo ou protocolo, e limites de tempo, complexidade e variedade de entradas, gerar uma lista de entradas para tentar. Embora o fuzzing seja aleatório, ele não é exaustivo. Parâmetros como comprimento, composição e quantas variações a tentar são importantes para obter o impacto mais econômico do fuzzer. Observe os outputs para os inputs alimentados no sistema pelos fuzzers e veja se algo interessante acontece. Se ocorrer uma falha, determine porque isso aconteceu. Descubra a suposição subjacente que foi invalidada pelo input. [Craft exploit payloads] Colocar input especialmente criado no sistema que aproveita a fraqueza identificada através do fuzzing e permite alcançar os objetivos do atacante. Fuzzers frequentemente revelam formas de passar através dos filtros de validação de entrada e introduzir dados indesejados no sistema.

Algumas APIs irão retirar certos caracteres principais de uma sequência de parâmetros. Um adversário pode intencionalmente introduzir caracteres "fantasma" (caracteres extras que não afetam a validade do pedido na camada API) que permitem que a entrada passe pelos filtros e, portanto, processe a entrada do adversário. Isso ocorre quando a API alvo aceita dados de entrada em várias formas sintáticas e os interpreta da forma semântica equivalente, enquanto o filtro não leva em conta todo o espectro das formas sintáticas aceitáveis para a API alvo. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todos os pontos de entrada na aplicação. O adversário usa os pontos de entrada reunidos na fase "Explorar" como uma lista de alvos e injeta várias sequências de caracteres "Fantasma" para determinar como filtrá-los na aplicação. Usando o que o adversário aprendeu sobre como a aplicação filtra os dados de entrada, eles elaboram dados de entrada específicos que passam por cima do filtro. Isso pode levar a ataques de travessia de diretório, execução arbitrária de comandos shell, corrupção de arquivos, etc.

Este ataque depende do uso de Cookies HTTP para armazenar credenciais, informações de estado e outros dados críticos nos sistemas dos clientes. Existem várias formas diferentes deste ataque. A primeira forma deste ataque envolve o acesso a Cookies HTTP ao meu para obter dados potencialmente sensíveis contidos nos mesmos. A segunda forma envolve interceptar esses dados à medida que são transmitidos do cliente para o servidor. Esta informação interceptada é então usada pelo adversário para se fazer passar pelo usuário/sessão remota. O terceiro formulário é quando o conteúdo do cookie é modificado pelo adversário antes de ser enviado de volta para o servidor. Aqui o adversário procura convencer o servidor alvo a operar sobre esta informação falsificada. Obter cópia do cookie] O adversário precisa primeiro obter uma cópia do cookie. O adversário pode ser um usuário final legítimo querendo aumentar o privilégio, ou pode ser alguém farejando em uma rede para obter uma cópia dos cookies HTTP. O adversário pode ser capaz de obter informações sensíveis a partir do cookie. Os desenvolvedores de aplicativos web podem ter assumido que os cookies não são acessíveis pelos usuários finais e, portanto, podem ter colocado informações potencialmente sensíveis neles. O adversário pode ser capaz de modificar ou substituir os cookies para contornar os controles de segurança do aplicativo.

Um atacante explora uma fraqueza na rotina de conversão MIME para causar um buffer overflow e ganhar controle sobre a máquina do servidor de e-mail. O sistema MIME é projetado para permitir que vários formatos diferentes de informação sejam interpretados e enviados via e-mail. Existem pontos de ataque quando os dados são convertidos para um formato compatível com MIME e vice-versa. O adversário identifica um servidor de e-mail alvo que ele deseja atacar. Determinar a viabilidade do ataque] Determinar se o servidor de e-mail não está remendado e se é potencialmente vulnerável a um dos conhecidos estouros de conversão MIME (por exemplo, Sendmail 8.8.3 e 8.8.4). Identificar locais no sistema onde rotinas vulneráveis de conversão MIME podem ser usadas. O adversário envia mensagens de e-mail com cabeçalhos especiais que irão causar um buffer overflow para a rotina de conversão de MIME vulnerável. A intenção deste ataque é aproveitar o overflow para execução de código arbitrário e obter acesso à máquina do servidor de e-mail, de modo que o adversário crie um e-mail que não apenas transborde o buffer alvo, mas o faça de modo que o endereço de retorno sobrescrito seja substituído por um dos escolhidos pelo adversário. Enviar mensagens de e-mail para o sistema alvo com cabeçalhos especialmente criados que acionam o buffer overflow e executam o código da shell.

Um atacante fornece o software alvo com dados de entrada que contêm sequências de caracteres especiais concebidas para contornar a lógica de validação de entrada. Esta exploração depende de o alvo fazer múltiplas passagens sobre os dados de entrada e processar uma "camada" de caracteres especiais com cada passagem. Desta forma, o atacante pode disfarçar a entrada que de outra forma seria rejeitada como inválida, escondendo-a com camadas de caracteres especiais/escape que são removidos por etapas de processamento subsequentes. O objetivo é primeiro descobrir casos em que a camada de validação de entrada executa antes de uma ou mais camadas de análise. Ou seja, a entrada do usuário pode passar pela seguinte lógica em uma aplicação: <parser1> --> <input validator> --> <parser2>. Nesses casos, o atacante precisará fornecer um input que passará pelo validador de input, mas depois de passar pelo parser2, será convertido em algo que o validador de input deveria ter parado. O atacante primeiro precisa determinar todos os inputs da aplicação/sistema onde a validação dos inputs está sendo feita e onde eles querem contorná-la. Determinar quais codificações de caracteres são aceitas pela aplicação/sistema] O atacante precisa então fornecer várias codificações de caracteres para a aplicação/sistema e determinar quais são aceitas. O atacante precisará observar a resposta da aplicação/sistema aos dados codificados para determinar se os dados foram interpretados corretamente. O atacante agora combina codificações aceitas pela aplicação. O atacante pode combinar diferentes codificações ou aplicar a mesma codificação várias vezes. O atacante aproveita sua capacidade de ignorar a validação de entrada para obter acesso não autorizado ao sistema. Há muitos ataques possíveis, e alguns exemplos são mencionados aqui.

Este tipo de ataque alavanca o uso de links simbólicos para causar estouros de buffer. Um adversário pode tentar criar ou manipular um arquivo de link simbólico de tal forma que seu conteúdo resulte em dados fora dos limites. Quando o software alvo processa o arquivo de link simbólico, ele pode potencialmente transbordar os buffers internos com verificação insuficiente dos limites. O adversário identifica uma aplicação ou programa alvo que pode carregar em certos arquivos para a memória. O adversário identifica um vetor de injeção para entregar o conteúdo excessivo ao buffer da aplicação alvo. [Sobrecarga do conteúdo do arquivo de sobrecarga] O adversário elabora o conteúdo a ser injetado. Se a intenção é simplesmente causar o travamento do software, o conteúdo só precisa consistir em uma quantidade excessiva de dados aleatórios. Se a intenção é alavancar o overflow para a execução de código arbitrário, o adversário prepara a carga de tal forma que o endereço de retorno sobrescrito é substituído por um dos escolhidos pelo adversário. Usando o conteúdo do arquivo especialmente criado, o adversário cria um link simbólico do recurso identificado para o arquivo malicioso, causando um ataque de sobrecarga do buffer.

Este tipo de ataque alavanca o uso de tags ou variáveis de um dado de configuração formatado para causar o buffer overflow. O adversário cria uma página HTML maliciosa ou um arquivo de configuração que inclui strings oversized, causando assim um overflow. O adversário identifica uma aplicação ou programa alvo para realizar o estouro do buffer. Os adversários procuram aplicações ou programas que aceitam arquivos formatados, como arquivos de configuração, como entrada. O adversário identifica um vetor de injeção para entregar o conteúdo excessivo ao buffer da aplicação alvo. O adversário elabora o conteúdo a ser injetado. Se a intenção é simplesmente causar o travamento do software, o conteúdo só precisa consistir em uma quantidade excessiva de dados aleatórios. Se a intenção é alavancar o overflow para a execução de código arbitrário, o adversário prepara a carga de tal forma que o endereço de retorno sobrescrito é substituído por um dos escolhidos pelo adversário. O adversário carregará o arquivo criado para a aplicação, causando um estouro de buffer.

Neste ataque, o software alvo recebe um input que o adversário sabe que será modificado e expandido em tamanho durante o processamento. Este ataque depende da falha do software alvo em prever que os dados expandidos podem exceder algum limite interno, criando assim um buffer overflow. O adversário identifica uma aplicação ou programa alvo para executar o buffer overflow on. Os adversários frequentemente procuram aplicações que aceitam a entrada do usuário e que realizam o gerenciamento manual da memória. O adversário identifica um vetor de injeção para entregar o conteúdo excessivo ao buffer da aplicação alvo. O adversário elabora o input a ser dado ao programa. Se a intenção é simplesmente causar o travamento do software, a entrada só precisa expandir para uma quantidade excessiva de dados aleatórios. Se a intenção é alavancar o overflow para execução de código arbitrário, o adversário irá criar um input que se expande de forma que não só transborde o buffer alvo, mas o faça de tal forma que o endereço de retorno sobrescrito seja substituído por um dos adversários, escolhendo quais pontos do código injetado pelo adversário. Usando o vetor de injeção, o adversário dá o input trabalhado para o programa, transbordando o buffer.

Um invasor gera uma mensagem ou bloco de dados que faz com que o destinatário acredite que a mensagem ou bloco de dados foi gerado e assinado criptograficamente por uma fonte autorizada ou confiável, induzindo a vítima ou sistema operacional da vítima a executar ações maliciosas.

Um adversário incorpora um ou mais bytes nulos na entrada do software alvo. Este ataque depende do uso de um byte de valor nulo como terminador de string em muitos ambientes. O objetivo é que certos componentes do software alvo parem de processar o input quando ele encontra o(s) byte(s) nulo(s). Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todos os pontos de entrada na aplicação. O adversário usa os pontos de entrada coletados na fase "Explore" como uma lista de alvos e injeta byte(s) postfix null byte(s) para observar como a aplicação lida com eles como input. O adversário está procurando por áreas onde o input do usuário é colocado no meio de uma string, e o byte nulo faz com que a aplicação pare de processar a string no final do input do usuário. Após determinados pontos de entrada que são vulneráveis, o adversário coloca um byte(s) nulo(s) de tal forma que eles removem os dados após o(s) byte(s) nulo(s) de uma maneira que seja benéfica para eles.

Se uma string for passada através de algum tipo de filtro, então um terminal NULL pode não ser válido. Usando a representação alternativa do NULL permite que um adversário incorpore o NULL mid-string enquanto pós fixação dos dados apropriados para que o filtro seja evitado. Um exemplo é um filtro que procura por um caractere de barra móvel. Se uma inserção de string é possível, mas a barra deve existir, uma codificação alternativa do NULL no meio da corda pode ser usada. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todos os pontos de entrada na aplicação. O adversário usa os pontos de entrada coletados na fase "Explore" como uma lista de alvos e injeta byte(s) postfix null byte(s) seguido por uma barra invertida para observar como a aplicação lida com eles como entrada. O adversário está procurando por áreas onde o input do usuário é colocado no meio de uma string, e o byte nulo faz com que a aplicação pare de processar a string no final do input do usuário. Após determinados pontos de entrada que são vulneráveis, o adversário coloca um byte nulo seguido por uma barra invertida de modo que eles contornem um filtro de entrada e removam os dados após o(s) byte(s) nulo(s) de uma maneira que seja benéfica para eles.

Este tipo de ataque é uma forma de Cross-Site Scripting (XSS) onde um script malicioso é inserido no HTML do lado do cliente sendo analisado por um web browser. O conteúdo servido por uma aplicação web vulnerável inclui código de script usado para manipular o Document Object Model (DOM). Este código de script ou não valida corretamente a entrada, ou não executa a codificação de saída apropriada, criando assim uma oportunidade para um adversário injetar um script malicioso para lançar um ataque XSS. Uma distinção chave entre outros ataques XSS e ataques baseados em DOM é que em outros ataques XSS, o script malicioso é executado quando a página da Web vulnerável é carregada inicialmente, enquanto um ataque baseado em DOM é executado algum tempo depois que a página é carregada. Outra distinção entre ataques baseados em DOM é que em alguns casos, o script malicioso nunca é enviado para o servidor vulnerável da web. Um ataque como este é garantido para contornar qualquer tentativa de filtragem do lado do servidor para proteger os usuários. Usando um navegador ou uma ferramenta automatizada, um adversário segue todos os links e ações públicas em um site da Web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O adversário usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injeta várias cargas úteis e caracteres especiais de script comuns para determinar se um ponto de entrada realmente representa uma vulnerabilidade e para caracterizar a extensão em que a vulnerabilidade pode ser explorada. Especificamente para o XSS baseado em DOM, o adversário está à procura de áreas onde o input está a ser usado para alterar directamente o DOM. Uma vez que o adversário tenha determinado quais parâmetros são vulneráveis ao XSS, ele irá criar um URL malicioso contendo a exploração do XSS. O adversário pode ter muitos objetivos, desde roubar IDs de sessão, cookies, credenciais e conteúdo de página da vítima. No XSS baseado em DOM, o script malicioso pode nem sequer ser enviado para o servidor, uma vez que o navegador da vítima irá manipular o próprio DOM. Isso pode ajudar a evitar mecanismos de detecção do lado do servidor. Para que o ataque seja bem-sucedido, a vítima precisa acessar o URL malicioso.

Um adversário incorpora scripts maliciosos em conteúdos que serão servidos aos navegadores de internet. O objetivo do ataque é que o software alvo, o browser do lado do cliente, execute o script com o nível de privilégio do usuário. Um ataque deste tipo explora as vulnerabilidades de um programa que são trazidas ao permitir que hosts remotos executem código e scripts. Navegadores web, por exemplo, têm alguns controles de segurança simples, mas se um atacante remoto tem permissão para executar scripts (injetando-os em conteúdo gerado pelo usuário, como quadros de avisos), então esses controles podem ser contornados. Além disso, estes ataques são muito difíceis de detectar para um usuário final. Usando um navegador ou uma ferramenta automatizada, um atacante segue todos os links e ações públicas em um site da web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O atacante usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injecta várias cargas úteis de script comuns para determinar se um ponto de entrada realmente representa uma vulnerabilidade e para caracterizar até que ponto a vulnerabilidade pode ser explorada. Como o atacante consegue explorar a vulnerabilidade, ele pode optar por roubar as credenciais do usuário para reutilizá-las ou analisá-las posteriormente. [Navegação forçada] Quando o atacante ataca o aplicativo atual ou outro (através de vulnerabilidades do CSRF), o usuário será então aquele que executa os ataques sem estar ciente disso. Estes ataques são na maioria das vezes direcionados a falhas de lógica da aplicação, mas também podem ser usados para criar um ataque generalizado contra um determinado site na rede atual do usuário (Internet ou não). Ao manipular o conteúdo, o atacante visa as informações que o usuário gostaria de obter do site.

Este ataque visa a codificação do URL combinado com a codificação dos caracteres da barra. Um atacante pode tirar vantagem das múltiplas formas de codificação de um URL e abusar da interpretação do URL. Um URL pode conter caracteres especiais que precisam de um tratamento de sintaxe especial para serem interpretados. Caracteres especiais são representados usando um caractere percentual seguido por dois dígitos que representam o código do octeto do caractere original (%HEX-CODE). Por exemplo, o caractere de espaço US-ASCII seria representado com %20. Isto é frequentemente referido como final fugido ou codificação percentual. Como o servidor decodifica a URL das requisições, ele pode restringir o acesso a alguns caminhos de URL, validando e filtrando as requisições de URL recebidas. Um atacante tentará criar uma URL com uma sequência de caracteres especiais que uma vez interpretada pelo servidor será equivalente a uma URL proibida. Pode ser difícil proteger contra esse ataque, uma vez que a URL pode conter outro formato de codificação como codificação UTF-8, codificação Unicode, etc. O atacante acessa o servidor usando um URL específico. O atacante tenta codificar alguns caracteres especiais no URL. O atacante descobre que alguns caracteres não são filtrados corretamente. O atacante faz um pedido de string de URL malicioso e o envia para o servidor. O servidor decodifica e interpreta a cadeia de URLs. Infelizmente como a filtragem de entrada não é feita apropriadamente, os caracteres especiais têm conseqüências prejudiciais.

[Encontrar aplicação de destino] Encontrar aplicação web de destino que aceita uma entrada de usuário e recupera dados do servidor [Examinar solicitações de aplicação existentes] Examinar solicitações HTTP/GET para visualizar o formato da consulta URL. Adversaries testam para ver se esse tipo de ataque é possível através de fraquezas na proteção de um aplicativo para Falsificação de solicitação do lado do servidor [Solicitação maliciosa] O Adversary cria uma solicitação URL maliciosa que assume o nível de privilégio do servidor para consultar serviços de rede internos ou externos e envia a solicitação para o aplicativo

Este ataque visa aplicações e softwares que utilizam a função syslog() de forma insegura. Se uma aplicação não explicite o uso de um parâmetro de formatação de string em uma chamada ao syslog(), a entrada do usuário pode ser colocada no parâmetro de formatação de string levando a um ataque de formatação de string. Os adversos podem então injetar comandos maliciosos de formatação de string na chamada de função levando a um buffer overflow. Há muitas vulnerabilidades de software relatadas com a causa raiz sendo um mau uso da função syslog(). O adversário identifica uma aplicação ou programa alvo para executar o buffer overflow on. Neste ataque, os adversários procuram por aplicações que utilizam o syslog() incorretamente. O adversário identifica um vetor de injeção para entregar o conteúdo excessivo ao buffer da aplicação alvo. Para cada entrada controlável pelo usuário que o adversário suspeita estar vulnerável à injeção de formato de string, tente injetar caracteres de formatação como %n, %s, etc.. O objetivo é manipular a criação da string usando esses caracteres de formatação. O adversário prepara o conteúdo a ser injetado. Se a intenção é simplesmente causar o travamento do software, o conteúdo só precisa consistir em uma quantidade excessiva de dados aleatórios. Se a intenção é aproveitar o estouro para a execução de código arbitrário, o adversário irá criar um conjunto de conteúdo que não só transborda o buffer alvo, mas o faz de tal forma que o endereço de retorno sobrescrito é substituído por um dos adversários que escolhe o código injetado pelo adversário. Usando o vector de injecção, o adversário fornece o programa com a injecção da string de formatação, causando um buffer.

Injeção SQL cega resulta de uma mitigação insuficiente para a injeção SQL. Embora a supressão de mensagens de erro da base de dados seja considerada a melhor prática, a supressão por si só não é suficiente para prevenir a SQL Injection. Blind SQL Injection é uma forma de SQL Injection que supera a falta de mensagens de erro. Sem as mensagens de erro que facilitam a SQL Injection, o adversário constrói cadeias de entrada que sonda o alvo através de expressões SQL Booleanas simples. O adversário pode determinar se a sintaxe e estrutura da injeção foi bem sucedida com base na execução ou não da consulta. Aplicado iterativamente, o adversário determina como e onde o alvo é vulnerável à SQL Injection. Hypothesize SQL queries in application] [Determinar como injetar informação nas consultas] [Determinar entrada controlável pelo usuário suscetível a injeção] Determinar a entrada controlável pelo usuário suscetível a injeção. Para cada entrada controlável pelo usuário que o adversário suspeita estar vulnerável à injeção SQL, tente injetar os valores determinados na etapa anterior. Se um erro não ocorrer, então o adversário sabe que a injeção SQL foi bem sucedida. Determina o tipo do banco de dados, como MS SQL Server ou Oracle ou MySQL, usando condições lógicas como parte das consultas injetadas [Extrair informações sobre o esquema do banco de dados] Extrair informações sobre o esquema do banco de dados fazendo com que o banco de dados responda sim/não a perguntas sobre o esquema. Usar as informações obtidas nos passos anteriores para injetar a base de dados com sucesso, a fim de contornar verificações ou modificar, adicionar, recuperar ou excluir dados da base de dados.

Um atacante pode fornecer uma cadeia Unicode para um componente do sistema que não esteja ciente do Unicode e usar isso para contornar o filtro ou fazer com que o mecanismo de classificação não compreenda adequadamente o pedido. Isso pode permitir ao atacante passar dados maliciosos pelo filtro de conteúdo e/ou possivelmente fazer com que o aplicativo encaminhe o pedido de forma incorreta. Usando um navegador ou uma ferramenta automatizada, um atacante segue todos os links e ações públicas em um site da Web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O atacante usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injeta várias cargas úteis codificadas Unicode para determinar se um ponto de entrada realmente representa uma vulnerabilidade com lógica de validação insuficiente e para caracterizar a extensão em que a vulnerabilidade pode ser explorada.

Este ataque tem como alvo a codificação do URL. Um adversário pode tirar vantagem da forma múltipla de codificação de um URL e abusar da interpretação do URL. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todas as URLs que contêm parâmetros. O adversário usa as URLs coletadas na fase "Explore" como uma lista de alvos e testa parâmetros com diferentes codificações de caracteres especiais para ver como a aplicação web irá lidar com elas. Usando as informações coletadas na fase "Experimentar", o adversário injeta caracteres especiais na URL usando a codificação da URL. Isso pode levar a travessias de caminho, scripts de cross-site, injeção SQL, etc.

Um ataque desse tipo envolve um adversário que insere caracteres maliciosos (como um redirecionamento XSS) em um nome de arquivo, direta ou indiretamente, que é então usado pelo software alvo para gerar texto HTML ou outro conteúdo potencialmente executável. Muitos sites dependem de conteúdo gerado pelo usuário e criam recursos dinamicamente, como arquivos, nomes de arquivos e links de URL, diretamente dos dados fornecidos pelo usuário. Nesse padrão de ataque, o invasor carrega o código que pode ser executado no navegador do cliente e / ou redireciona o navegador do cliente para um site de propriedade do invasor. Todas as variantes de carga útil de ataque XSS podem ser usadas para passar e explorar essas vulnerabilidades.

Este ataque visa o uso da contrabarra na codificação alternativa. Um adversário pode fornecer uma barra invertida como personagem principal e faz com que um interpretador acredite que o próximo personagem é especial. Isto é chamado de fuga. Ao usar esse truque, o adversário tenta explorar formas alternativas de codificar o mesmo personagem, o que leva a problemas de filtragem e abre caminhos para o ataque. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todos os pontos de entrada na aplicação. O adversário usa os pontos de entrada reunidos na fase "Explorar" como uma lista de alvos e tenta escapar de vários caracteres especiais diferentes usando uma barra invertida. Uma vez que o adversário determina como contornar filtros que filtram caracteres especiais usando uma barra de escape, ele irá manipular a entrada do usuário de uma forma que não é pretendida pela aplicação.

Este ataque tem como alvo a codificação dos caracteres Slash. Um adversário tentaria explorar problemas comuns de filtragem relacionados com o uso dos caracteres Slash para obter acesso a recursos no hospedeiro alvo. Os sistemas guiados por directórios, tais como sistemas de ficheiros e bases de dados, tipicamente utilizam o carácter cortante para indicar a passagem entre directórios ou outros componentes do contentor. Por razões históricas obscuras, os PCs (e, como resultado, os sistemas operacionais da Microsoft) optam por usar uma barra invertida, enquanto o mundo UNIX tipicamente faz uso da barra invertida para frente. O resultado esquizofrênico é que muitos sistemas baseados em MS são necessários para entender ambas as formas da barra. Isto dá ao adversário muitas oportunidades para descobrir e abusar de uma série de problemas de filtragem comuns. O objetivo deste padrão é descobrir software de servidor que só aplica filtros a uma versão, mas não à outra. Usando um navegador, uma ferramenta automatizada ou inspecionando a aplicação, um adversário registra todos os pontos de entrada na aplicação. O adversário usa os pontos de entrada reunidos na fase "Explorar" como uma lista de destino e procura áreas onde o input do usuário é usado para acessar recursos no host de destino. O adversário tenta diferentes codificações de caracteres slash para contornar os filtros de entrada. Uma vez que o adversário determina como contornar filtros que filtram caracteres barra, ele irá manipular a entrada do usuário para incluir barras para atravessar diretórios e acessar recursos que não são destinados ao usuário.

Este ataque tem como alvo bibliotecas ou módulos de código compartilhado que são vulneráveis a ataques de buffer overflow. Um adversário que tenha conhecimento de bibliotecas vulneráveis conhecidas ou de código compartilhado pode facilmente ter como alvo software que faça uso dessas bibliotecas. Todos os clientes que fazem uso da biblioteca de código tornam-se assim vulneráveis por associação. Isto tem um efeito muito amplo na segurança de um sistema, geralmente afetando mais de um processo de software. O adversário, com conhecimento de bibliotecas vulneráveis ou módulos de código compartilhado, identifica uma aplicação ou programa alvo que faz uso delas. O adversário tenta usar a API, e se eles podem enviar uma grande quantidade de dados para ver se o ataque de buffer overflow realmente funciona. O adversário elabora o conteúdo a ser injetado com base em seu conhecimento da vulnerabilidade e do resultado desejado. Se a intenção é simplesmente causar o colapso do software, o conteúdo só precisa consistir em uma quantidade excessiva de dados aleatórios. Se a intenção é alavancar o excesso para a execução de código arbitrário, o adversário irá criar um conjunto de conteúdo que não só transborda o buffer alvo, mas o faz de tal forma que o endereço de retorno sobrescrito é substituído por um dos adversários que escolhe o código injetado pelo adversário. Usando a API como vetor de injeção, o adversário injeta o conteúdo de sobrecarga no buffer.

Este ataque é uma variação específica no aproveitamento de codificações alternativas para contornar a lógica de validação. Esse ataque alavanca a possibilidade de codificar entradas potencialmente prejudiciais em UTF-8 e submetê-las a aplicações que não esperam ou são eficazes na validação desse padrão de codificação, dificultando a filtragem das entradas. O UTF-8 (8-bit UCS/Unicode Transformation Format) é uma codificação de caracteres de comprimento variável para Unicode. Os caracteres UTF-8 legais têm de um a quatro bytes de comprimento. Entretanto, a versão inicial da especificação UTF-8 obteve algumas entradas erradas (em alguns casos, permitiu caracteres muito longos). Os codificadores UTF-8 devem usar a codificação "mais curta possível", mas decodificadores ingênuos podem aceitar codificações que sejam mais longas do que o necessário. De acordo com o RFC 3629, uma forma particularmente sutil deste ataque pode ser realizada contra um analisador que realiza verificações de validade críticas de segurança contra a forma codificada UTF-8 de sua entrada, mas interpreta certas seqüências ilegais de octetos como caracteres. Usando um navegador ou uma ferramenta automatizada, um atacante segue todos os links e ações públicas em um site da web. Eles registram todos os links, os formulários, os recursos acessados e todos os outros pontos de entrada potenciais para a aplicação web. O atacante usa os pontos de entrada reunidos na fase "Explore" como uma lista de alvos e injeta várias cargas úteis codificadas UTF-8 para determinar se um ponto de entrada realmente representa uma vulnerabilidade com lógica de validação insuficiente e para caracterizar a extensão em que a vulnerabilidade pode ser explorada.

Ataques de Web Logs Ataques de adulteração envolvem um atacante que injecta, elimina ou de outra forma adultera o conteúdo dos Web logs normalmente com o objectivo de mascarar outros comportamentos maliciosos. Além disso, escrever dados maliciosos em arquivos de log pode ter como alvo trabalhos, filtros, relatórios e outros agentes que processam os logs em um padrão de ataque assíncrono. Este padrão de ataque é similar ao "Log Injection-Tampering-Forging", exceto que, neste caso, o ataque tem como alvo os logs do servidor web e não a aplicação. O atacante observa o sistema e procura por indicadores de qual utilitário de registro está sendo usado pelo servidor web. Determine Injectable Content] O atacante lança várias ações registradas com dados maliciosos para determinar que tipo de injeção de registro é possível. O atacante altera o conteúdo do log diretamente através de manipulação ou forjamento ou indiretamente através da injeção de uma solicitação especialmente elaborada que o servidor web receberá e escreverá nos logs. Este tipo de ataque normalmente segue outro ataque e é usado para tentar cobrir os vestígios do ataque anterior.

Um atacante pode criar uma entrada especial, controlável pelo usuário, que consiste em expressões XPath para injetar a base de dados XML e ignorar a autenticação ou obter informações que normalmente não seriam capazes de fazer. XPath Injection permite que um atacante fale diretamente com a base de dados XML, contornando assim completamente a aplicação. XPath Injection resulta da falha de uma aplicação em higienizar corretamente as entradas usadas como parte das expressões dinâmicas XPath usadas para consultar uma base de dados XML. Usando um navegador ou uma ferramenta automatizada, um adversário registra todas as instâncias de entrada controlável pelo usuário usadas para contrastar as consultas XPath. Usando meios manuais ou automatizados, testar as entradas encontradas para os pontos fracos do XPath. Injectar conteúdo na consulta XPath] Criar conteúdo malicioso contendo expressões XPath que não é validado pela aplicação e é executado como parte das consultas XPath.

Este ataque utiliza as frequentes viagens de ida e volta cliente-servidor na conversa Ajax para digitalizar um sistema. Embora o Ajax não abra novas vulnerabilidades per se, ele as otimiza do ponto de vista de um atacante. Um primeiro passo comum para um atacante é pegar o rastro do ambiente alvo para entender que ataques irão funcionar. Como a pegada baseia-se na enumeração, o padrão de conversa de solicitações e respostas rápidas e múltiplas que são típicas nos aplicativos Ajax permitem que um atacante procure por muitas vulnerabilidades, portas conhecidas, localizações de rede e assim por diante. O conhecimento adquirido através do Ajax fingerprinting pode ser usado para suportar outros ataques, como o XSS. Usando um navegador ou uma ferramenta automatizada, um adversário envia solicitações para uma página da Web e registra a resposta HTML recebida. Os adversários então analisam o HTML para identificar quaisquer arquiteturas JavaScript subjacentes conhecidas. Isso pode ajudar no mapepiong vulnerabilidades conhecidas publicamente para a página web e também pode ajudar o adversário a adivinhar a arquitetura da aplicação e o funcionamento interno de um sistema.

Neste tipo de ataque, um adversário injeta comandos do sistema operacional em funções existentes da aplicação. Uma aplicação que usa entrada não confiável para construir strings de comando é vulnerável. Um adversário pode alavancar a injeção de comandos do SO em uma aplicação para elevar privilégios, executar comandos arbitrários e comprometer o sistema operacional subjacente. O atacante determina o input controlável pelo usuário que é passado como parte de um comando para o sistema operacional subjacente. O atacante faz o levantamento da aplicação alvo, possivelmente como um usuário válido e autenticado [Variar entradas, procurando por resultados maliciosos]. Dependendo se a aplicação a ser explorada é remota ou local, o atacante cria a entrada maliciosa apropriada, contendo comandos do SO, para ser passada para a aplicação [Executar comandos maliciosos] O atacante pode roubar informações, instalar um mecanismo de acesso de porta traseira, elevar privilégios ou comprometer o sistema de alguma outra forma.

Este ataque visa utilitários de linha de comando disponíveis em vários shells. Um adversário pode aproveitar uma vulnerabilidade encontrada em um utilitário de linha de comando para aumentar o privilégio para root. Identificar sistema alvo] O adversário primeiro encontra um sistema alvo no qual ele quer ganhar privilégios elevados. Este pode ser um sistema ao qual eles já têm algum nível de acesso ou um sistema ao qual eles ganharão acesso não autorizado a um privilégio inferior usando algum outro meio. O adversário identifica utilitários de linha de comando expostos pela máquina alvo que contêm vulnerabilidades de buffer overflow. O adversário provavelmente sabe quais utilitários têm essas vulnerabilidades e quais são as versões afetadas, então eles também obterão números de versão para esses utilitários. Uma vez que o adversário tenha encontrado um utilitário vulnerável, ele usará seu conhecimento da vulnerabilidade para criar o comando que irá explorar o buffer overflow. Usando o vetor de injeção, o adversário executa o comando crafted, ganhando privilégios elevados na máquina.