Por padrão, servidores ASP.NET armazenam na memória o objeto HttpSessionState, seus atributos e quaisquer objetos aos quais eles fazem referência. Esse modelo limita o estado da sessão ativa que pode ser acomodado pela memória do sistema de uma única máquina. Para ampliar a capacidade além dessas limitações, os servidores são frequentemente configurados para informações de estado de sessão persistentes, o que expande a capacidade e também permite a replicação através de várias máquinas a fim de melhorar o desempenho global. Para persistir o estado de sua sessão, o servidor deve serializar o objeto HttpSessionState, o que requer que todos os objetos nele armazenados sejam serializáveis.

Para que a sessão seja serializada corretamente, todos os objetos que o aplicativo armazena como atributos de sessão devem declarar o atributo [Serializable]. Além disso, se o objeto exigir métodos de serialização personalizados, ele também deverá implementar a interface ISerializable.

Exemplo 1: A classe a seguir se acrescenta à sessão, mas, como não é serializável, a sessão não pode ser serializada corretamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

Se vários threads estiverem tentando obter um bloqueio em um recurso, chamar sleep() enquanto um bloqueio é mantido pode fazer com que todos os outros threads aguardem a liberação desse recurso, o que pode resultar na piora do desempenho e em um deadlock.

Exemplo 1: O código a seguir chama sleep() enquanto mantém um bloqueio.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

Muitos indivíduos talentosos passaram muito tempo pensando em maneiras de fazer o bloqueio duplamente verificado funcionar a fim de melhorarem o desempenho. Nenhum deles conseguiu.

Exemplo 1: À primeira vista, pode parecer que o seguinte trecho de código obtém a segurança de threads e, ao mesmo, evita a sincronização desnecessária.

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

O programador quer garantir que apenas um objeto Fitzer() sempre seja alocado, mas não quer pagar o custo de sincronização cada vez que esse código é chamado. Essa expressão idiomática é conhecida como bloqueio duplamente verificado.

Infelizmente, ele não funciona, e vários objetos Fitzer() podem ser alocados. Consulte a declaração "O bloqueio duplamente verificado está quebrado" para obter mais detalhes [1].

Depois que um thread sinaliza outros threads à espera de um mutex, ele deve desbloquear esse mutex chamando pthread_mutex_unlock() antes que a execução de outro thread possa começar. Se o thread de sinalização não conseguir desbloquear o mutex, a chamada pthread_cond_wait() no segundo thread não será retornada, e o thread não será executado.

Exemplo 1: O código a seguir sinaliza outro thread aguardando em um mutex chamando pthread_cond_signal(), mas não consegue desbloquear esse mutex no qual o outro thread está aguardando.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

Aplicativos exigem arquivos temporários com tanta frequência, que existem muitos mecanismos diferentes para criá-los na Biblioteca C e na API do Windows(R). A maioria dessas funções é vulnerável a várias formas de ataque.
Exemplo: O código a seguir usa um arquivo temporário para armazenar dados intermediários coletados da rede antes que eles sejam processados.

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

Esse código, que de outra forma seria desinteressante, é vulnerável a uma série de ataques diferentes, pois se baseia em um método inseguro para a criação de arquivos temporários. As vulnerabilidades introduzidas por essa função e outras estão descritas nas próximas seções. Os problemas de segurança mais graves relacionados com a criação de arquivos temporários têm ocorrido em sistemas operacionais baseados no Unix, mas os aplicativos do Windows apresentam riscos paralelos. Esta seção inclui uma discussão sobre a criação de arquivos temporários em sistemas Unix e Windows.

Os métodos e comportamentos podem variar entre sistemas, mas os riscos fundamentais introduzidos por cada um são razoavelmente constantes. Consulte a seção Recomendações para obter informações sobre funções básicas de linguagem de segurança e orientações a respeito de uma abordagem segura para a criação de arquivos temporários.

As funções projetadas para auxiliar na criação de arquivos temporários podem ser divididas em dois grupos com base no fato de simplesmente fornecerem um nome de arquivo ou de realmente abrirem um novo arquivo.

Grupo 1 - Nomes de arquivos "exclusivos":

O primeiro grupo de funções da Biblioteca C e da WinAPI projetadas para ajudar no processo de criação de arquivos temporários trabalha gerando um nome de arquivo exclusivo para um novo arquivo temporário, que o programa então deve abrir. Esse grupo inclui funções da Biblioteca C como tmpnam(), tempnam(), mktemp() e seus equivalentes em C ++ prefaciados com um _ (sublinhado), bem como a função GetTempFileName() da API do Windows. Esse grupo de funções é afetado por uma condição de corrida subjacente no nome do arquivo escolhido. Embora as funções garantam que o nome do arquivo é exclusivo no momento em que é selecionado, não existe nenhum mecanismo para impedir que outro processo ou um invasor crie um arquivo com o mesmo nome após essa seleção, mas antes de o aplicativo tentar abri-lo. Além do risco de uma colisão legítima causada por outra chamada para a mesma função, há uma alta probabilidade de que um invasor seja capaz de criar uma colisão mal-intencionada, pois os nomes de arquivos gerados por essas funções não são suficientemente aleatórios a ponto de os tornar difíceis de adivinhar.

Se um arquivo com o nome selecionado for criado, dependendo de como esse arquivo for aberto, seu conteúdo ou suas permissões de acesso existentes poderão permanecer intactos. Se o conteúdo existente do arquivo for realmente mal-intencionado, um invasor talvez seja capaz de injetar dados perigosos no aplicativo quando este lê dados provenientes do arquivo temporário. Se um invasor criar o arquivo previamente com permissões brandas de acesso, os dados armazenados no arquivo temporário pelo aplicativo poderão ser acessados, modificados ou corrompidos por esse invasor. Em sistemas baseados no Unix, um ataque ainda mais traiçoeiro é possível quando o invasor cria o arquivo previamente como um link para outro arquivo importante. Dessa forma, se o aplicativo truncar ou gravar dados no arquivo, ele poderá realizar involuntariamente operações prejudiciais para favorecer o invasor. Trata-se de uma ameaça especialmente grave nos casos em que o programa opera com permissões elevadas.

Por fim, na melhor das hipóteses, o arquivo será aberto com uma chamada para open() usando os sinalizadores O_CREAT e O_EXCL ou para CreateFile() usando o atributo CREATE_NEW, o que falhará se o arquivo já existir, impedindo assim os tipos de ataques descritos anteriormente. No entanto, se um invasor for capaz de prever com precisão uma sequência de nomes de arquivos temporários, o aplicativo poderá ser impedido de abrir o armazenamento temporário necessário, causando um ataque de negação de serviço (DoS). Considerando a pequena quantidade de aleatoriedade usada na seleção dos nomes de arquivos gerados por essas funções, não é difícil elaborar esse tipo de ataque.

Grupo 2 - Arquivos "exclusivos":

O segundo grupo de funções da Biblioteca C tenta resolver alguns dos problemas de segurança relacionados a arquivos temporários, não só gerando um nome de arquivo exclusivo, como também abrindo esse arquivo. Esse grupo inclui funções da Biblioteca C, como tmpfile() e seus equivalentes em C++ prefaciados com um _ (sublinhado), bem como a função mkstemp() da Biblioteca C, que apresenta um comportamento um pouco melhor.

As funções ao estilo tmpfile() constroem um nome de arquivo exclusivo e abrem esse arquivo da mesma maneira que fopen() faria se os sinalizadores "wb+" fossem transmitidos, ou seja, como um arquivo binário no modo de leitura/gravação. Se o arquivo já existir, tmpfile() vai truncá-lo no tamanho zero, possivelmente em uma tentativa de acalmar as preocupações de segurança mencionadas anteriormente a respeito da condição de corrida existente entre a seleção de um nome de arquivo supostamente exclusivo e a subsequente abertura do arquivo selecionado. No entanto, esse comportamento claramente não resolve os problemas de segurança da função. Em primeiro lugar, um invasor pode criar o arquivo previamente com permissões brandas de acesso que provavelmente serão mantidas pelo arquivo aberto por tmpfile(). Além disso, em sistemas baseados no Unix, se o invasor criar o arquivo previamente como um link para outro arquivo importante, o aplicativo poderá usar suas permissões possivelmente elevadas para truncar esse arquivo, provocando danos em nome do invasor. Por fim, se tmpfile() criar um novo arquivo, as permissões de acesso aplicadas a esse arquivo vão variar de um sistema operacional para outro, o que pode deixar os dados do aplicativo vulneráveis mesmo que um invasor não seja capaz de prever com antecedência o nome do arquivo a ser usado.

Em última análise, mkstemp() é uma forma razoavelmente segura de criar arquivos temporários. Essa função tentará criar e abrir um arquivo exclusivo com base em um modelo de nome de arquivo fornecido pelo usuário, combinado com uma série de caracteres aleatoriamente gerados. Se ela não conseguir criar esse arquivo, falhará e retornará -1. Em sistemas modernos, o arquivo é aberto com o uso do modo 0600, o que significa que o arquivo ficará protegido contra adulteração, a menos que o usuário altere explicitamente suas permissões de acesso. No entanto, mkstemp() ainda sofre com o uso de nomes de arquivos previsíveis e poderá deixar um aplicativo vulnerável a ataques de negação de serviço se um invasor provocar a falha de mkstemp() ao prever e criar previamente os nomes de arquivo a serem utilizados.

Quanto mais tempo uma sessão permanecer aberta, maior será janela de oportunidade que um invasor terá para comprometer as contas dos usuários. Enquanto uma sessão permanece ativa, um invasor pode ser capaz de obter a senha de um usuário por força bruta, quebrar a chave de criptografia sem fio de um usuário ou comandar uma sessão a partir de um navegador aberto. Tempos limite de sessão mais longos também podem evitar a liberação da memória e eventualmente resultar em uma negação de serviço se um número suficientemente grande de sessões for criado.

Exemplo 1: O código no exemplo a seguir define um valor negativo para o intervalo inativo máximo, resultando em uma sessão que permanece ativa indefinidamente.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Nunca é uma boa ideia um aplicativo Web tentar desligar o contêiner do aplicativo. Uma chamada para um método de encerramento é provavelmente parte de um código de depuração restante ou de um código importado de um aplicativo não J2EE.

Um aplicativo J2EE pode fazer uso de várias JVMs para melhorar o desempenho e a confiabilidade dos aplicativos. Para que as várias JVMs apareçam como um único aplicativo para o usuário final, o contêiner J2EE pode replicar um objeto HttpSession em várias JVMs de forma que, se uma JVM se tornar indisponível, outra poderá entrar e tomar o seu lugar sem interromper o fluxo do aplicativo.

Para que a replicação da sessão funcione, os valores que o aplicativo armazena como atributos na sessão devem implementar a interface Serializable.

Exemplo 1: A classe a seguir se adiciona à sessão, mas, como não é serializável, a sessão já não pode mais ser replicada.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

O gerenciamento de threads em um aplicativo Web é proibido pelo padrão J2EE em algumas circunstâncias e é sempre muito propenso a erros. O gerenciamento de threads é difícil e pode interferir de maneiras imprevisíveis com o comportamento do contêiner do aplicativo. Mesmo sem interferir com o contêiner, o gerenciamento de threads geralmente provoca bugs que são difíceis de detectar e diagnosticar, como deadlocks, condições de corrida e outros erros de sincronização.

O Node.js permite que os desenvolvedores atribuam retornos de chamada aos eventos bloqueados por E/S. Isso permite um melhor desempenho, pois os retornos de chamada são executados de forma assíncrona, de tal forma que o aplicativo principal não seja bloqueada por E/S. No entanto, por sua vez, isso pode levar a condições de corrida quando algo fora da chamada de retorno depende que código no retorno de chamada seja executado primeiro.

Exemplo 1: O código a seguir verifica um usuário em relação a um banco de dados para autenticação.

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

Nesse exemplo, supostamente estaríamos chamando um banco de dados back-end para confirmar as credenciais de um usuário para login e, se confirmadas, definimos uma variável para true, caso contrário, false. Infelizmente, uma vez que o retorno de chamada é bloqueado por E/S, ele será executado de forma assíncrona e poderá ser executado após a verificação para if (authenticated), e, como o padrão era verdadeiro, ele vai para a if-statement quer o o usuário esteja realmente autenticado ou não.

O aplicativo instala um aplicativo do armazenamento compartilhado no qual qualquer aplicativo com permissões de leitura/gravação de armazenamento externo pode gravar. Devido a uma condição de corrida, o aplicativo malicioso que monitora a pasta pode trocar um arquivo APK baixado por um arquivo APK alternativo, que o processo de instalação usará no lugar da atualização legítima.

Exemplo 1: O código a seguir instala um aplicativo do armazenamento compartilhado:

    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(new File(Environment.getExternalStorageDirectory() + "/download/" + "app.apk")), "application/vnd.android.package-archive");
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

Os métodos parse() e format() em java.text.Format contêm uma condição de corrida que pode fazer com que um usuário veja os dados de outro usuário.

Exemplo 1: O código a seguir mostra como essa falha de design pode se manifestar.

public class Common {

    private static SimpleDateFormat dateFormat;
    ...

    public String format(Date date) {
        return dateFormat.format(date);
    }
    ...

    final OtherClass dateFormatAccess=new OtherClass();
    ...

    public void function_running_in_thread1(){
        System.out.println("Time in thread 1 should be 12/31/69 4:00 PM, found: "+ dateFormatAccess.format(new Date(0)));
    }

    public void function_running_in_thread2(){
        System.out.println("Time in thread 2 should be around 12/29/09 6:26 AM, found: "+ dateFormatAccess.format(new Date(System.currentTimeMillis())));
    }
}

Embora esse código se comporte corretamente em um ambiente de usuário único, se dois threads puderem executá-lo ao mesmo tempo, eles poderão produzir a seguinte saída:

O horário em thread 1 deve ser 12/31/69 4:00 PM, encontrado: 12/31/69 4:00 PM
O horário em thread 2 deve ser por volta de 12/29/09 6:26 AM, encontrado: 12/31/69 4:00 PM

Nesse caso, a data do primeiro thread é mostrada na saída do segundo thread devido a uma condição de corrida na implementação de format().

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.