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: O código a seguir chama realloc() em um buffer que contém 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.

Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. No entanto, um dos campos mutáveis da classe tinha um método mutante chamado nele fora do construtor e do destruidor.

Exemplo 1: O código a seguir para uma classe final imutável declara um Set private e final e, em seguida, cria erroneamente um método que transforma o Set.

@Immutable
public final class ThreeStooges {
  private final Set stooges = new HashSet>();
  ...

  public void addStooge(String name) {
    stooges.add(name);
  }
  ...
}

Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. Um campo não final viola a imutabilidade da classe permitindo que o valor seja alterado.

Exemplo 1: O código a seguir para uma classe final imutável declara erroneamente um campo public e não final.

@Immutable
public class ImmutableInteger {
public int value;

}