As propriedades RoamingFolder e RoamingSettings obtêm um contêiner no repositório de dados do aplicativo em roaming, que pode então ser usado para compartilhar dados entre mais dois dispositivos. Ao gravar e ler objetos armazenados no repositório de dados do aplicativo móvel, o desenvolvedor aumenta o risco de comprometimento. Isso inclui a confidencialidade, a integridade e a disponibilidade dos dados, aplicativos e sistemas que compartilham esses objetos por meio do repositório de dados em roaming.

Os desenvolvedores devem evitar o uso dessa funcionalidade sem primeiro implementar os controles técnicos necessários.

Condições de corrida de manipulação de sinais podem ocorrer sempre que uma função instalada como um manipulador de sinais é não reentrante, ou seja, mantém um certo estado interno ou chama outra função que realiza isso. Essas condições de corrida são ainda mais prováveis quando a mesma função é instalada para lidar com vários sinais.

Condições de corrida de manipulação de sinais apresentam mais chances de ocorrer quando:

1. O programa instala um único manipulador de sinais para mais de um sinal.

2. Dois sinais diferentes para os quais o manipulador está instalado chegam em curta sucessão, causando uma condição de corrida no manipulador de sinais.

Exemplo: O código a seguir instala o mesmo manipulador de sinais simples não reentrante para dois sinais diferentes. Se um invasor fizer com que os sinais sejam enviados nos momentos certos, o manipulador de sinais passará por uma vulnerabilidade de liberação dupla. Chamar free() duas vezes no mesmo valor pode resultar em um buffer overflow. Quando um programa chama free() duas vezes com o mesmo argumento, as estruturas de dados de gerenciamento de memória desse programa se tornam corrompidas. Essa corrupção pode fazer com que o programa trave ou, em algumas circunstâncias, com que duas chamadas posteriores para malloc() retornem o mesmo apontador. Se malloc() retornar o mesmo valor duas vezes, e, mais tarde, o programa der ao invasor controle sobre os dados que são gravados nessa memória duplamente alocada, o programa se tornará vulnerável a um ataque de buffer overflow.

void sh(int dummy) {
  ...
  free(global2);
  free(global1);
  ...
}

int main(int argc,char* argv[]) {
  ...
  signal(SIGHUP,sh);
  signal(SIGTERM,sh);
  ...
}

Muitos desenvolvedores de Servlet não entendem que um Servlet é um singleton. Há apenas uma instância dele, que é utilizada e reutilizada para lidar com várias solicitações que são processadas simultaneamente por diferentes threads.

Um resultado comum desse mal-entendido é que os desenvolvedores usam campos membros do Servlet de tal maneira que um usuário pode inadvertidamente ver os dados de outro usuário. Em outras palavras, o armazenamento de dados do usuário em campos membros do Servlet introduz uma condição de corrida de acesso a dados.

Exemplo 1: O Servlet a seguir armazena o valor de um parâmetro de solicitação em um campo membro e depois ecoa esse valor de parâmetro para o fluxo de saída da resposta.

public class GuestBook extends HttpServlet {

   String name;

   protected void doPost (HttpServletRequest req, HttpServletResponse res) {
     name = req.getParameter("name");
     ...
     out.println(name + ", thanks for visiting!");
   }
}

Embora esse código funcione perfeitamente em um ambiente de usuário único, se dois usuários acessarem o Servlet aproximadamente ao mesmo tempo, é possível que os dois threads do manipulador de solicitação sejam intercalados da seguinte maneira:

Thread 1: atribuir "Dick" a name
Thread 2: atribuir "Jane" a name
Thread 1: imprimir "Jane, thanks for visiting!"
Thread 2: imprimir "Jane, thanks for visiting!"

Mostrando assim ao primeiro usuário o nome do segundo usuário.

Um objeto de recurso transacional, como uma conexão de banco de dados, só pode ser associado a uma transação de cada vez. Por esse motivo, uma conexão não deve ser compartilhada entre threads e não deve ser armazenada em um campo estático. Consulte a Seção 4.2.3 da Especificação J2EE para obter mais detalhes.

Exemplo 1:

public class ConnectionManager {

private static Connection conn = initDbConn();
...
}

Vulnerabilidades de fixação de sessão ocorrem quando:

1. Um aplicativo Web autentica um usuário sem primeiro invalidar a sessão existente, continuando assim a utilizar a sessão já associada ao usuário.
2. Um invasor pode forçar um identificador de sessão conhecido para um usuário, de modo que, uma vez que o usuário seja autenticado, o invasor tenha acesso à sessão autenticada.

Na exploração genérica de vulnerabilidades de fixação de sessão, o invasor cria uma nova sessão em um aplicativo Web e registra o identificador de sessão associado. Em seguida, o invasor faz com que a vítima se autentique no servidor usando esse identificador de sessão, o que dá a ele acesso à conta do usuário através da sessão ativa.

Algumas estruturas, como o Spring Security, invalidam automaticamente as sessões existentes ao criar uma nova. Esse comportamento pode ser desabilitado, deixando o aplicativo vulnerável a esse ataque.

Exemplo 1: O exemplo a seguir mostra um trecho de um aplicativo protegido do Spring Security em que a proteção de fixação da sessão foi desabilitada.

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

Mesmo com um aplicativo vulnerável, para que o ataque específico descrito aqui tenha êxito, é necessário que haja vários fatores favoráveis ao invasor: acesso a um terminal público não monitorado, capacidade de manter a sessão comprometida ativa e uma vítima interessada em fazer logon no aplicativo vulnerável no terminal público. Na maioria das circunstâncias, os dois primeiros desafios são contornáveis com um investimento de tempo suficiente. Encontrar uma vítima que esteja ao mesmo tempo utilizando um terminal público e queira fazer login no aplicativo vulnerável também é possível, desde que o local seja razoavelmente popular. Quanto menos popular for o local, menor será a probabilidade de uma vítima se interessar em usar o terminal público e menores as chances de sucesso para o vetor de ataque descrito anteriormente.

O maior desafio que um invasor enfrenta ao explorar vulnerabilidades de fixação de sessão é induzir as vítimas a se autenticarem no aplicativo vulnerável usando um identificador de sessão conhecido pelo invasor. No Example 1, o invasor faz isso por meio de um método direto óbvio que não se adapta bem a ataques que envolvem sites menos conhecidos. No entanto, não se deixe convencer pela complacência; os invasores têm muitas ferramentas que ajudam a contornar as limitações desse vetor de ataque. A técnica mais comum usada pelos invasores consiste em tirar proveito de vulnerabilidades de cross-site scripting ou divisão de respostas HTTP no site de destino [1]. Enganando a vítima para induzi-la a enviar uma solicitação mal-intencionada a um aplicativo vulnerável que reflete JavaScript ou outro código de volta para o navegador da vítima, um invasor pode criar um cookie que faz com que a pessoa reutilize um identificador de sessão controlado por ele.

É interessante notar que cookies estão frequentemente vinculados ao domínio de nível superior associado a determinada URL. Se vários aplicativos residirem no mesmo domínio de nível superior, como bank.example.com e recipes.example.com, uma vulnerabilidade em um aplicativo poderá permitir que um invasor defina um cookie com um identificador de sessão fixo usado em todas as interações com qualquer aplicativo no domínio example.com [2].

Outros vetores de ataque incluem envenenamento de DNS e ataques baseados em rede relacionados, em que um invasor induz o usuário a acessar um site mal-intencionado redirecionando uma solicitação de um site válido. Os ataques baseados em rede geralmente envolvem uma presença física na rede da vítima ou o controle de um computador comprometido na rede, o que os torna mais difíceis de explorar remotamente. Porém, sua importância não deve ser menosprezada. Mecanismos de gerenciamento de sessão menos seguros, como a implementação padrão no Apache Tomcat, permitem que identificadores de sessão normalmente esperados em um cookie sejam especificados na URL também. Isso permite que um invasor induza uma vítima a usar um identificador de sessão fixo simplesmente enviando uma URL mal-intencionada por email.