A anotação FortifyDangerous foi aplicada a esse campo. Ela é usada para indicar que o método é perigoso, e todos os seus usos devem ser examinados quanto à segurança.

Certas funções comportam-se de maneiras perigosas, independentemente de como são usadas. As funções nessa categoria foram muitas vezes implementadas sem levar preocupações de segurança em consideração.

Certas funções comportam-se de maneiras perigosas, independentemente de como são usadas. As funções nessa categoria foram muitas vezes implementadas sem levar preocupações de segurança em consideração.

Certas funções se comportam perigosamente, independentemente de como são usadas. As funções nesta categoria foram frequentemente implementadas sem consideração pela segurança.

Exemplo 1: Dada a URL http://www.example.com/index.php?param=..., o seguinte trecho de código php em index.php imprimirá o valor do parâmetro de URL param (passado no lugar de "...") na tela se ele corresponder à expressão regular POSIX '^[[:alnum:]]*$' que representa "zero ou mais caracteres alfanuméricos":

  <?php
    $pattern = '^[[:alnum:]]*$';
    $string = $_GET['param'];
    if (ereg($pattern, $string)) {
      echo($string);
    }
  ?>

Embora o Example 1 funcione conforme esperado na entrada alfanumérica, como a função ereg() não segura é usada para validar a entrada contaminada, é possível realizar um ataque cross-site scripting (XSS) por meio da injeção de byte null. Passar um valor param que contém uma string alfanumérica válida, seguida por um byte null e uma marca <script> (ex.: "Hello123%00<script>alert("XSS")</script>"), ereg($pattern, $string) ainda retornará true, já que a função ereg() ignora tudo após um caractere de byte null ao ler a string de entrada (esquerda para direita). Neste exemplo, isso significa que a marca <script> inserida após o byte null será exibida para o usuário e avaliada.

Certas funções comportam-se de maneiras perigosas, independentemente de como são usadas. A função xp_cmdshell inicializa uma shell de comando do Windows para executar a cadeia de comando fornecida. O comando é executado no sistema padrão ou em um contexto de proxy fornecido. No entanto, não há qualquer maneira de limitar um usuário a um conjunto pré-especificado de operações privilegiadas e qualquer concessão de privilégios permite o usuário a executar qualquer cadeia de comando.

A anotação FortifyDangerous foi aplicada a esse método. Ela é usada para indicar que o método é perigoso, e todos os seus usos devem ser examinados quanto à segurança.

A anotação FortifyDangerous foi aplicada a esse tipo. Ela é usada para indicar que o método é perigoso, e todos os seus usos devem ser examinados quanto à segurança.

A chamada de sistema chroot() permite que um processo altere sua percepção do diretório raiz do sistema de arquivos. Depois de invocar chroot() corretamente, um processo não pode acessar arquivos fora da árvore de diretórios definida pelo novo diretório raiz. Esse ambiente recebe o nome de prisão chroot e é comumente utilizado para impedir que um processo possa ser corrompido e usado para acessar arquivos não autorizados. Por exemplo, muitos servidores FTP são executados em prisões chroot para impedir que um invasor que descobrir uma nova vulnerabilidade em um servidor seja capaz de baixar o arquivo de senha ou outros arquivos confidenciais do sistema.

O uso indevido de chroot() pode permitir que os invasores escapem da prisão chroot. A chamada de função chroot() não altera o diretório de trabalho atual do processo e, portanto, caminhos relativos ainda podem fazer referência a recursos do sistema de arquivos fora da prisão chroot depois que chroot() é chamada.

Exemplo 1: Considere o seguinte código-fonte de um servidor FTP (hipotético):

chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
  fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);

Esse código é responsável pela leitura de um nome de arquivo na rede, pela abertura do arquivo correspondente na máquina local e pelo envio do conteúdo na rede. Esse código pode ser usado para implementar o comando FTP GET. O servidor FTP chama chroot() em suas rotinas de inicialização, na tentativa de impedir o acesso a arquivos fora de /var/ftproot. Porém, como o servidor não consegue alterar o diretório de trabalho atual chamando chdir("/"), um invasor poderia solicitar o arquivo "../../../../../etc/passwd"e obter uma cópia do arquivo de senha do sistema.

A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean não deve usar a funcionalidade AWT para tentar a saída de informações em um monitor ou para inserir informações usando um teclado."

Uma exigência que a especificação justifica da seguinte maneira:

"Os servidores não permitem interação direta entre um programa de aplicativo e um teclado/tela conectado ao sistema do servidor."

A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"O enterprise bean não deve tentar criar um carregador de classes; definir o carregador de classes de contexto; definir o gerenciador de segurança; criar um novo gerenciador de segurança; parar a JVM; ou alterar os fluxos de entrada, saída e erro."

Uma exigência que a especificação justifica da seguinte maneira:

"Essas funções são reservadas para o contêiner do Enterprise Beans. Permitir que o enterprise bean use essas funções pode comprometer a segurança e diminuir a capacidade do contêiner de gerenciar adequadamente o ambiente de tempo de execução."

A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean deve ter cuidado ao usar o pacote Java I/O para tentar acessar arquivos e diretórios no sistema de arquivos."

Uma exigência que a especificação justifica da seguinte maneira:

"As APIs do sistema de arquivos não são adequadas para que componentes de negócios acessem dados. Os arquivos podem não estar acessíveis em todas as instâncias, ou seu conteúdo pode ser diferente em instâncias diferentes, e coordenar as atualizações do arquivo pode ser difícil. Os componentes de negócios devem usar uma API de gerenciador de recursos, como JDBC, para armazenar dados."

A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean não deve tentar escutar em um soquete, aceitar conexões em um soquete ou usar um soquete para multitransmissão."

Uma exigência que a especificação justifica da seguinte maneira:

"A arquitetura do Enterprise Beans permite que uma instância de enterprise bean seja um cliente de soquete de rede, mas não permite que ela seja um servidor de rede. Permitir que a instância se torne um servidor de rede entraria em conflito com a função básica do enterprise bean: atender aos clientes do Enterprise Beans."

A especificação Enterprise JavaBeans exige que todos os fornecedores de beans sigam um conjunto de orientações de programação destinadas a assegurar que o bean será portátil e terá um comportamento consistente em qualquer contêiner EJB [1].

Neste caso, o programa viola a seguinte orientação EJB:

"Um enterprise bean não deve usar primitivas de sincronização de threads para sincronizar a execução de várias instâncias, a menos que seja um singleton session bean com simultaneidade gerenciada por bean."

Uma exigência que a especificação justifica da seguinte maneira:

"Essa regra é necessária para garantir uma semântica em tempo de execução consistente, pois, embora alguns contêineres do Enterprise Beans possam usar uma única JVM para executar todas as instâncias do enterprise bean, outros podem distribuir essas instâncias entre várias JVMs."

A divulgação de arquivos ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são usados para construir dinamicamente um caminho.

Exemplo 1: Este código usa dados não confiáveis e os usa para abrir um arquivo que é retornado ao usuário.

from django.http import FileResponse
...
def file_disclosure(request):
    path = request.GET['returnURL']
    return FileResponse(open(path, 'rb'))
...

Se um invasor fornecesse uma URL com o parâmetro de solicitação correspondente a um local de arquivo sensível, ele seria capaz de visualizar esse arquivo. Por exemplo, "http://www.yourcorp.com/webApp/logic?returnURL=settings.py" permitiria a eles visualizar o "settings.py" do aplicativo.

Uma divulgação de arquivos ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são usados para construir dinamicamente um caminho.

Exemplo 1: O código a seguir usa dados não confiáveis para construir um caminho que é usado em um redirecionamento no lado do servidor.

...
String returnURL = request.getParameter("returnURL");
	RequestDispatcher rd = request.getRequestDispatcher(returnURL);
	rd.forward();
...

Exemplo 2: O código a seguir usa dados não confiáveis para construir um caminho que é usado em um redirecionamento no lado do servidor.

...
	<% String returnURL = request.getParameter("returnURL"); %>
	<jsp:include page="<%=returnURL%>" />
	...

Se um invasor fornecesse uma URL com o parâmetro de solicitação correspondente a um local de arquivo sensível, ele seria capaz de visualizar esse arquivo. Por exemplo, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" permitiria visualizar o arquivo applicationContext.xml do aplicativo.
Depois que o invasor tiver applicationContext.xml, ele poderia localizar e baixar outros arquivos de configuração referenciados nesse arquivo ou até mesmo em arquivos de classe ou jar. Isso permitiria que os invasores obtivessem informações confidenciais sobre um aplicativo e as direcionassem para outros tipos de ataques.

Uma divulgação de arquivos ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são usados para construir dinamicamente um caminho.

Exemplo 1: O código a seguir usa dados não confiáveis para construir um caminho que é usado em um redirecionamento no lado do servidor.

...
	String returnURL = request.getParameter("returnURL");
	return new ModelAndView(returnURL);
	...

Se um invasor fornecesse uma URL com o parâmetro de solicitação correspondente a um local de arquivo sensível, ele seria capaz de visualizar esse arquivo. Por exemplo, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" permitiria visualizar o arquivo applicationContext.xml do aplicativo.
Depois que o invasor tiver applicationContext.xml, ele poderia localizar e baixar outros arquivos de configuração referenciados nesse arquivo ou até mesmo em arquivos de classe ou jar. Isso permitiria que os invasores obtivessem informações confidenciais sobre um aplicativo e as direcionassem para outros tipos de ataques.

No Spring Webflow, um resolvedor de visualização é usado para traduzir o nome de uma visualização em uma tecnologia de renderização real. Normalmente, um resolvedor de visualização limitará o tipo e a localização dos arquivos usando prefixos e sufixos. No entanto, o uso de parâmetros de solicitação para especificar o nome da visualização permite que esse mecanismo seja contornado.
Exemplo 1: As seguintes configurações do Spring Webflow usam parâmetros de solicitação para especificar o nome da visualização.

<webflow:end-state id="finalStep" view="${requestParameters.url}"/>
<webflow:view-state id="showView" view="${requestParameters.test}">

O resolvedor de visualização padrão do Spring Webflow destina-se a permitir que apenas arquivos jsp em "/ WEB-INF / views /" sejam resolvidos.

<bean class="org.springframework.web.servlet.view.
               InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/" />
    <property name="suffix" value=".jsp" />
</bean>

Um invasor pode usar o seguinte URL para visualizar o arquivo applicationContext.xml: "http://www.yourcorp.com/webApp/logic?url=../applicationContext.xml;x="
O InternalResourceViewResolver pegará o prefixo com o qual está configurado, concatenará o valor passado no atributo de visualização e finalmente adicionará o sufixo.
A URL relativa resultante, "/WEB-INF/views/../applicationContext.xml;x=.jsp" é passada para o distribuidor de solicitações do lado do servidor. O ponto e vírgula permite que o invasor converta o sufixo ".jsp" em um parâmetro de caminho. Este ataque pode ser usado para divulgar qualquer arquivo na raiz do aplicativo da web.

Uma divulgação de arquivos ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são usados para construir dinamicamente um caminho.

Exemplo 1: O código a seguir usa dados não confiáveis para construir um caminho que é usado em um redirecionamento no lado do servidor.

...
	String returnURL = request.getParameter("returnURL");
	return new ActionForward(returnURL);
	...

Se um invasor fornecesse uma URL com o parâmetro de solicitação correspondente a um local de arquivo sensível, ele seria capaz de visualizar esse arquivo. Por exemplo, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" permitiria visualizar o arquivo applicationContext.xml do aplicativo.
Depois que o invasor tiver applicationContext.xml, ele poderia localizar e baixar outros arquivos de configuração referenciados nesse arquivo ou até mesmo em arquivos de classe ou jar. Isso permitiria que os invasores obtivessem informações confidenciais sobre um aplicativo e as direcionassem para outros tipos de ataques.

As vulnerabilidades de inspeção de heap ocorrem quando dados confidenciais, como uma senha ou uma chave de criptografia, podem ser expostos a um invasor porque não foram removidos da memória.

A função realloc() costuma ser usada para aumentar o tamanho de um bloco de memória alocada. Muitas vezes, essa operação requer a cópia do conteúdo do bloco de memória antigo em um bloco novo e maior. Essa operação deixa o conteúdo do bloco original intacto, mas inacessível ao programa, impedindo que ele consiga limpar dados confidenciais da memória. Se mais tarde um invasor puder examinar o conteúdo de um despejo de memória, os dados confidenciais poderão ficar expostos.

Exemplo 1: O código a seguir chama realloc() em um buffer contendo dados confidenciais:

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

Há uma tentativa de limpar os dados confidenciais da memória, mas, como realloc() é usado, uma cópia dos dados ainda pode ser exposta na memória originalmente alocada para plaintext_buffer.

As vulnerabilidades de inspeção de heap ocorrem quando dados confidenciais, como uma senha ou uma chave de criptografia, podem ser expostos a um invasor porque não foram removidos da memória.

A função VirtualLock destina-se a bloquear páginas na memória para impedir que elas sejam paginadas no disco. No entanto, no Windows 95/98/ME, a função é implementada apenas como rascunho e não tem nenhum efeito.