A API AccessibleObject permite que o programador contorne as verificações de controle de acesso fornecidas por especificadores de acesso Java. Em particular, ela possibilita que o programador permita que um objeto refletido contorne controles de acesso Java e, por sua vez, altere o valor de campos particulares ou invoque métodos privados, comportamentos que são normalmente proibidos.

Em um aplicativo JSF regular, os valores são convertidos e validados usando conversores e validadores especificados pelos componentes de IU. A conversão e validação em si acontecem quando a página é enviada. Uma visualização favoritável de um aplicativo Fusion resulta no não envio da página e, portanto, nenhuma conversão ou validação semelhante é realizada por padrão.

Exemplo 1: O seguinte trecho de um arquivo de configuração mostra uma amostra de visualização favoritável, configurada para não realizar conversão ou validação do parâmetro do URL paramName.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Vulnerabilidades de Sequestro de Carregamento de Classe Android assumem duas formas:

- Um invasor pode alterar o nome dos diretórios pesquisados pelo programa para carregar classes, apontando o caminho para um diretório sobre o qual ele tem controle: o invasor controla explicitamente os caminhos que devem ser pesquisados em busca de classes.

- Um invasor pode alterar o ambiente no qual a classe é carregada: o invasor controla implicitamente o que o nome do caminho significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar os diretórios pesquisados por classes a serem carregadas. Vulnerabilidades de Sequestro de Carregamento de Classe Android desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa um diretório de biblioteca para procurar classes a serem carregadas.



3. Ao executar o código no caminho da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir usa o userClassPath alterável pelo usuário para determinar o diretório no qual procurar classes a serem carregadas.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Esse código permite que um invasor carregue uma biblioteca e execute possivelmente um código arbitrário com o privilégio elevado do aplicativo, sendo capaz de modificar o resultado de userClassPath de forma que ele aponte para um caminho diferente que o invasor pode controlar. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor de userClassPath, ele poderá enganar o aplicativo de forma com que este aponte para um diretório controlado pelo invasor e, portanto, poderá carregar as classes que ele definiu usando os mesmos privilégios que o aplicativo original.

Exemplo 2: O código a seguir usa a userOutput modificável pelo usuário para determinar o diretório em que os arquivos DEX otimizados devem ser escritos.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Esse código permite que um invasor especifique o diretório de saída para arquivos DEX otimizados (ODEX). Isso então permite que um usuário mal-intencionado altere o valor de userOutput para um diretório que ele pode controlar, como um armazenamento externo. Quando isso for conseguido, será simplesmente uma questão de substituir o arquivo ODEX processado por um arquivo ODEX mal-intencionado para que este seja executado com os mesmos privilégios do aplicativo original.

Entradas não verificadas são a principal causa de vulnerabilidades em serviços de API da Web ASP.NET. Entradas não verificadas podem resultar em muitas vulnerabilidades, incluindo cross-site scripting, process control, access control e SQL injection. Embora serviços de API da Web ASP.NET geralmente não sejam suscetíveis a ataques de memory corruption, se esse tipo de serviço for chamado em um código nativo que não realiza a verificação de limites de array, um invasor talvez seja capaz de usar uma fraqueza de validação de entrada no serviço de API da Web ASP.NET para lançar um ataque de buffer overflow.

Para impedir esses ataques:
1. use os atributos de validação para anotar programaticamente verificações de validação em parâmetros ou membros de parâmetros de objeto de associação de modelos a ações de serviços de API da Web ASP.NET.
2. use ModelState.IsValid para verificar se a validação de modelo é aprovada.

Nomes e valores de propriedades de bean precisam ser validados antes do preenchimento de qualquer bean. Funções de preenchimento de beans permitem que os desenvolvedores definam uma propriedade de bean ou uma propriedade aninhada. Os invasores podem utilizar essa funcionalidade para acessar propriedades especiais de beans, como class.classLoader, o que permitirá que ele substitua as propriedades do sistema e potencialmente execute código arbitrário.

Exemplo: O código a seguir define uma propriedade de bean controlada pelo usuário sem a devida validação do nome da propriedade ou do valor:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente substituir os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Em geral, vulnerabilidades de buffer overflow ocorrem em um código que:

- Baseia-se em dados externos para controlar seu comportamento.

- Depende de propriedades dos dados que são aplicados fora do escopo imediato do código.

- É tão complexo que um programador não consegue prever seu comportamento com precisão.



Os exemplos a seguir demonstram todos esses três cenários.

Exemplo 1.a: O exemplo de código a seguir demonstra um buffer overflow simples que muitas vezes é causado pelo primeiro cenário, em que o código se baseia em dados externos para controlar seu comportamento. O código usa a função gets() para ler uma quantidade arbitrária de dados em um buffer de pilha. Como não há nenhuma maneira de limitar a quantidade de dados lida por essa função, a segurança do código depende de o usuário sempre inserir menos de BUFSIZE caracteres.

	...
	char buf[BUFSIZE];
	gets(buf);
	...

Exemplo 1.b: Este exemplo mostra como é fácil imitar o comportamento não seguro da função gets() em C++ usando o operador >> para ler a entrada em uma string char[].

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

Exemplo 2: O código neste exemplo também se baseia na entrada do usuário para controlar seu comportamento, mas adiciona um certo nível de desvio com o uso da função de cópia de memória limitada memcpy(). Essa função aceita um buffer de destino, um buffer de origem e o número de bytes a serem copiados. O buffer de entrada é preenchido por uma chamada limitada para read(), mas o usuário especifica o número de bytes que são copiados por memcpy().

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

Observação: Esse tipo de vulnerabilidade de buffer overflow (em que um programa lê os dados e depois confia em um valor desses dados em operações de memória subsequentes nos dados restantes) apareceu com uma determinada frequência em bibliotecas de imagem e áudio e também em outras bibliotecas de processamento de arquivos.

Exemplo 3: Este é um exemplo do segundo cenário, no qual o código depende de propriedades dos dados que não são verificadas localmente. Neste exemplo, uma função denominada lccopy() usa uma string como seu argumento e retorna uma cópia alocada por heap dessa string com letras maiúsculas convertidas em minúsculas. A função não realiza verificações de limites em sua entrada, pois espera que str sempre seja menor que BUFSIZE. Se um invasor ignorar as verificações no código que chama lccopy() ou se uma mudança nesse código tornar inválida a suposição sobre o tamanho de str, lccopy() fará o estouro de buf com a chamada ilimitada para strcpy().

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

Exemplo 4: O código a seguir demonstra o terceiro cenário em que o código é tão complexo que seu comportamento não pode ser facilmente previsto. Esse código vem do popular decodificador de imagens libPNG, que é usado por uma ampla variedade de aplicativos.

O código parece realizar a verificação de limites com segurança, pois verifica o tamanho do comprimento de variáveis, que ele utiliza mais tarde para controlar a quantidade de dados copiada por png_crc_read(). No entanto, logo antes de testar o comprimento, o código realiza uma verificação em png_ptr->mode e, se essa verificação falhar, um aviso será emitido e o processamento continuará. Como length é testado em um bloco else if, length não poderá ser testado se a primeira verificação falhar e será usado às cegas na chamada para png_crc_read(), possivelmente permitindo um buffer overflow de pilha.

Embora o código nesse exemplo não seja o mais complexo que vimos até agora, ele demonstra por que a complexidade deve ser minimizada no código que realiza operações de memória.

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

Exemplo 5: Este exemplo também demonstra o terceiro cenário, no qual a complexidade do programa o expõe a estouros de buffer. Nesse caso, a exposição é decorrente da interface ambígua de uma das funções, e não da estrutura do código (como foi o caso no exemplo anterior).

A função getUserInfo() usa um nome de usuário especificado como uma string de vários bytes e um apontador para uma estrutura de informações do usuário e preenche essa estrutura com informações sobre o usuário. Como a autenticação do Windows usa Unicode para nomes de usuário, o argumento username é primeiro convertido de uma string de vários bytes em uma string Unicode. Em seguida, essa função transmite incorretamente o tamanho de unicodeUser em bytes em vez de em caracteres. Portanto, a chamada para MultiByteToWideChar() pode gravar caracteres com um comprimento de até (UNLEN+1)*sizeof(WCHAR), ou
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, na matriz unicodeUser, que tem apenas (UNLEN+1)*sizeof(WCHAR) bytes alocados. Se a string username contiver mais de UNLEN caracteres, a chamada para MultiByteToWideChar() causará um estouro no buffer unicodeUser.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa grave além dos limites da memória alocada.

Exemplo: O código a seguir estoura c porque o tipo double requer mais espaço do que está alocado para c.

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa grave além dos limites da memória alocada.

Exemplo: O código a seguir estoura buf porque, dependendo do tamanho de f, o especificador de cadeia de formato "%d %.1f ... " pode exceder a quantidade de memória alocada.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de erro "off-by-one" ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e de pilha, entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Exemplo: O código a seguir contém um estouro de buffer "off-by-one", que ocorre quando recv retorna os bytes máximos permitidos de sizeof(buf) que foram lidos. Nesse caso, a desreferência subsequente de buf[nbytes] gravará o byte null fora dos limites da memória alocada.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Exemplo: O código a seguir tenta evitar um buffer overflow de leitura "off-by-one", verificando que o valor não confiável lido de getInputLength() é menor que o tamanho do buffer de destino output. No entanto, como a comparação entre len e MAX tem sinal, se len for negativo, ele se tornará um número positivo muito grande quando for convertido em um argumento sem sinal para memcpy().

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

Mecanismos de modelo são usados para renderizar conteúdo usando dados dinâmicos. Esses dados de contexto normalmente são controlados pelo usuário e formatados pelo modelo para gerar páginas da Web, e-mails, entre outros. Os mecanismos de modelo permitem que expressões de linguagem poderosas sejam usadas em modelos para renderizar conteúdo dinâmico, processando os dados de contexto com construções de código como condicionais, loops etc. Se um invasor puder controlar o modelo a ser renderizado, poderá injetar expressões que exponham dados de contexto e executem código mal-intencionado no navegador.

Exemplo 1: O exemplo a seguir mostra como um modelo é recuperado de uma URL e renderiza informações com AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

Nesse caso, $stateParams.expression obterá possivelmente dados controlados pelo usuário e os avaliará como um modelo a ser usado com um contexto especificado. Por sua vez, isso pode permitir que um usuário mal-intencionado execute qualquer código que ele desejar no navegador, recuperando informações sobre o contexto com base no qual ele é executado, encontrando informações adicionais sobre como o aplicativo é criado ou transformando isso em um completo ataque de XSS.

Vulnerabilidades de inclusão não autorizada ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação da Web.

2. Os dados fazem parte da string que especifica o atributo template de uma tag <cfinclude>.
Exemplo: O código a seguir usa a entrada de um formulário da Web para construir o caminho para um arquivo especial utilizado para formatar a página inicial do usuário. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo mal-intencionado, como "../../users/wileyh/malicious", que fará com que o aplicativo inclua e execute o conteúdo de um arquivo no diretório base do invasor.

<cfinclude template =  
              "C:\\custom\\templates\\#Form.username#.cfm">

Se um invasor tiver permissão para especificar o arquivo incluído pela tag <cfinclude>, ele poderá fazer com que o aplicativo inclua na página atual o conteúdo de quase qualquer arquivo do sistema de arquivos do servidor. Essa capacidade pode ser aproveitada de pelo menos duas maneiras significativas. Se um invasor puder gravar em uma localização no sistema de arquivos do servidor, como o diretório base do usuário ou um diretório de upload comum, ele pode fazer com que o aplicativo inclua um arquivo elaborado de maneira mal-intencionada na página, que em seguida será executado pelo servidor. Mesmo sem acesso de gravação ao sistema de arquivos do servidor, um invasor pode muitas vezes obter acesso a informações confidenciais ou privadas especificando o caminho de um arquivo no servidor.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.

2. Os dados são usados como uma string, ou parte de uma string, que representa um comando executado pelo aplicativo.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
System.Runtime.getRuntime().exec("make");
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas, como injeção de comandos, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 4: O código a seguir lê comandos a serem executados a partir de uma intenção do Android.

...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...

Em um dispositivo root, um aplicativo mal-intencionado pode forçar o aplicativo de uma vítima a executar comandos arbitrários com privilégios de superusuário.

Referências diretas a expressões do GitHub Action em um script de execução são geradas dinamicamente. Isso permite que qualquer pessoa com controle da entrada comprometa o sistema usando injeção de comando.

Exemplo 1: O código a seguir de um GitHub Action faz referência direta a uma expressão em um script de execução que deixa o sistema aberto para injeção de comando.

    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...
    

Quando a ação é executada, o script de shell é executado dinamicamente, incluindo qualquer código que o valor github.event.pull_request.title represente. Se o github.event.pull_request.title contiver código executável malicioso, a ação executará o código malicioso, o que resultará na injeção de comando.

Ataques de Connection String Parameter Pollution (CSPP) consistem em injetar parâmetros de cadeia de conexão em outros parâmetros existentes. Essa vulnerabilidade é semelhante a outras vulnerabilidades, e é talvez mais bem conhecida que, em ambientes HTTP nos quais a poluição de parâmetros também pode ocorrer. No entanto, também pode se aplicar a outros lugares, como cadeias de conexão do banco de dados. Se um aplicativo não limpar a entrada do usuário adequadamente, um usuário malicioso poderá comprometer a lógica do aplicativo para executar ataques: de roubo de credenciais até a recuperação de todo o banco de dados. Ao enviar parâmetros adicionais para uma aplicativo, e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, a conexão de banco de dados poderá reagir de uma das seguintes maneiras:

Ela poderá obter somente os dados do primeiro parâmetro
Ela poderá obter os dados do último parâmetro
Ela poderá obter os dados de todos os parâmetros e concatená-los

Isso pode depender do driver utilizado, do tipo de banco de dados ou até mesmo de como as APIs são utilizadas.

Exemplo 1: Este código usa entradas de uma solicitação HTTP para se conectar a um banco de dados:

      ...
      string password = Request.Form["db_pass"]; //gets POST parameter 'db_pass'
      SqlConnection DBconn = new SqlConnection("Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = " + password + ";");
      ...
    

Neste exemplo, o programador não considerou que um invasor poderia fornecer um parâmetro db_pass, como:
"xxx; Integrated Security = true", a cadeia de conexão se torna:

"Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = xxx; Integrated Security = true; "

Isso fará com que o aplicativo se conecte ao banco de dados usando a conta do sistema operacional sob a qual o aplicativo está em execução para ignorar a autenticação normal. Isso significaria que o atacante conseguiu se conectar ao banco de dados sem uma senha válida e realizar consultas diretamente no banco de dados.

Vulnerabilidades de injeção de string de consulta ocorrem quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma URL de consulta de Provedor de Conteúdo.



Provedores de conteúdo Android permitem que os desenvolvedores gravem consultas sem SQL simplesmente construindo URIs de provedor de conteúdo. URIs de consulta de provedores de conteúdo são vulneráveis a ataques de injeção e, portanto, os desenvolvedores devem evitar o uso da concatenação de strings com entradas de dados corrompidas para construir o URI, sem garantir que os metacaracteres estão devidamente validados ou codificados.

Exemplo 1: Considerando um aplicativo que expõe vários provedores de conteúdo em URIs:

content://my.authority/messagescontent://my.authority/messages/123content://my.authority/messages/deleted

Se os desenvolvedores construírem os URIs de consulta concatenando strings, os invasores poderão incluir barras no caminho ou outros metacaracteres de URI que modificarão o significado dessa consulta. No seguinte trecho de código, um invasor pode chamar content://my.authority/messages/deleted fornecendo um código msgId com o valor deleted:

// "msgId" is submitted by users
Uri dataUri = Uri.parse(WeatherContentProvider.CONTENT_URI + "/" + msgId);
Cursor wCursor1 = getContentResolver().query(dataUri, null, null, null, null);

APIs Flash fornecem uma interface para carregar arquivos SWF remotos no ambiente de execução existente. Mesmo que a política entre domínios definida só permita o carregamento de arquivos SWF a partir de uma lista de domínios confiáveis, na maioria dos casos, ela é excessivamente permissiva. Permitir que uma entrada de usuário não confiável defina quais arquivos SWF devem ser carregados pode fazer com que um conteúdo arbitrário seja referenciado e possivelmente executado pelo aplicativo intencionado, resultando em um ataque de criação de flash entre sites.

Vulnerabilidades de criação de flash entre sites ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são usados para carregar um arquivo SWF remoto.
Exemplo: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado como a URL a partir da qual carregar um arquivo SWF remoto.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   var ldr:Loader = new Loader();
   var urlReq:URLRequest = new URLRequest(url);
   ldr.load(urlReq);
   ...

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código JSP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O seguinte segmento de código JSP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, não fazem sentido — por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
	WebView webview = (WebView) findViewById(R.id.webview);
  	webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Várias estruturas modernas da Web fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Struts 2). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Vulnerabilidades de XSS (cross-site scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Para o navegador renderizar a resposta como HTML ou outro documento que possa executar scripts, ele deve especificar um tipo MIME text/html. Portanto, o XSS só será possível se a resposta usar esse tipo MIME ou qualquer outro que também force o navegador a renderizar a resposta como HTML ou outro documento que possa executar scripts, como imagens SVG. (image/svg+xml), documentos XML (application/xml), etc.

A maioria dos navegadores modernos não renderiza HTML ou executa scripts quando fornece uma resposta com tipos MIME, como application/octet-stream. No entanto, alguns navegadores, como o Internet Explorer, executam o que é conhecido como Content Sniffing. O Content Sniffing envolve ignorar o tipo MIME fornecido e tentar inferir o tipo MIME correto pelo conteúdo da resposta.
Vale a pena notar, no entanto, que um tipo MIME de text/html é apenas um tipo MIME que pode levar a vulnerabilidades de XSS. Outros documentos que podem executar scripts, como imagens SVG (image/svg+xml), documentos XML (application/xml), assim como outros, podem levar a vulnerabilidades de XSS, independentemente de o navegador executar o Content Sniffing.

Portanto, uma resposta, como <html><body><script>alert(1)</script></body></html>, poderia ser renderizada como HTML mesmo se seu cabeçalho content-type estivesse definido como application/octet-stream,multipart-mixed, e assim por diante.

Exemplo 1: O método JAX-RS a seguir reflete os dados do usuário em uma resposta application/octet-stream.

@RestController
public class SomeResource {
    @RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
    public String response5(@RequestParam(value="name") String name){
        return name;
	}
}

Se um invasor enviar uma solicitação com o parâmetro name definido como <html><body><script>alert(1)</script></body></html>, o servidor produzirá a seguinte resposta:

HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>

Mesmo assim, a resposta afirma claramente que deve ser tratada como um documento JSON, um navegador antigo ainda pode tentar processá-lo como um documento HTML, tornando-o vulnerável a um ataque de Cross-Site Scripting.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável. No caso do XSS baseado em DOM, os dados são lidos a partir de um parâmetro de URL ou de outro valor dentro do navegador e gravados de volta na página com o código do lado do cliente. No caso da XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso da XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação. No caso do XSS baseado em DOM, o conteúdo malicioso é executado como parte da criação do DOM (Document Object Model) sempre que o navegador da vítima analisar a página HTML.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo: O seguinte segmento de código JavaScript lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));

O código nesse exemplo funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.


Como o exemplos demonstra, as vulnerabilidades XSS são causadas por códigos que incluem dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- O aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.