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.

Valores associados a block.timestamp ou block.number são frequentemente usados por desenvolvedores para acionar eventos dependentes de tempo, no entanto, esses valores geralmente dão uma noção de tempo que geralmente não é segura para uso.

Devido à natureza descentralizada do blockchain, os nós podem sincronizar o tempo apenas até certo ponto. Na melhor das hipóteses, usar block.timestamp não é confiável e, na pior das hipóteses, mineradores mal-intencionados poderão alterar o carimbo de data/hora de seus blocos se perceberem uma vantagem em fazê-lo.

Quanto a block.number, embora seja possível prever o tempo entre os blocos (aproximadamente 14 segundos), os tempos dos blocos não são constantes e podem variar dependendo da atividade da rede. Isso torna block.number não confiável para cálculos relacionados ao tempo.

Exemplo 1: O código a seguir usa block.number para desbloquear fundos após um determinado período.

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

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);

Condições de corrida de acesso a arquivos, conhecidas condições de corrida TOCTOU (tempo de verificação/tempo de uso), ocorrem quando:

1. O programa verifica a propriedade de um arquivo, fazendo referência a esse arquivo por seu nome.

2. O programa executa posteriormente uma operação do sistema de arquivos usando o mesmo nome de arquivo e considera que a propriedade verificada anteriormente não foi alterada.
Exemplo 1: O código a seguir é de um programa instalado setuid root. O programa executa certas operações de arquivo em nome de usuários sem privilégios e usa verificações de acesso para garantir que ele não use seus privilégios de root para executar operações que não deveriam estar disponíveis ao usuário atual. O programa usa a chamada de sistema access() para verificar se a pessoa que está executando o programa tem permissão para acessar o arquivo especificado antes de abri-lo e executar as operações necessárias.

  if (!access(file,W_OK)) {
    f = fopen(file,"w+");
    operate(f);
    ...
  }
  else {
    fprintf(stderr,"Unable to open file %s.\n",file);
  }

A chamada para access() se comporta conforme o esperado, retornando 0 quando o usuário que está executando o programa tem as permissões necessárias para gravar no arquivo e -1 em outros casos. No entanto, como access() e fopen() operam ambos em nomes de arquivo em vez de em identificadores de arquivo, não há nenhuma garantia de que a variável file ao ser transmitida para fopen() ainda faça referência ao mesmo arquivo no disco de quando ela foi transmitida para access(). Se um invasor substituir file após a chamada para access() por um link simbólico para um arquivo diferente, o programa usará seus privilégios de root para operar nesse arquivo, mesmo que este seja um arquivo que o invasor seria incapaz de modificar em outras circunstâncias. Ao enganar o programa a ponto de fazer com que ele realizasse uma operação que de outra forma seria inadmissível, o invasor obteve privilégios elevados.

Esse tipo de vulnerabilidade não está limitado a programas com privilégios de root. Se o aplicativo for capaz de realizar qualquer operação que o invasor de outra forma não teria permissão para realizar, então ele será um possível alvo.

A janela de vulnerabilidade para tal ataque é o período entre o instante em que a propriedade é testada e o instante em que o arquivo é usado. Mesmo que o uso ocorra imediatamente após a verificação, os sistemas operacionais modernos não oferecem nenhuma garantia quanto ao volume de código que é executado antes de o processo liberar a CPU. Os invasores contam com uma variedade de técnicas para ampliar a janela de oportunidade e facilitar sua exploração. Entretanto, mesmo com uma janela pequena, uma tentativa de exploração pode ser repetidas várias e várias vezes, até ser bem-sucedida.

Exemplo 2: O código a seguir cria um arquivo e, em seguida, modifica seu proprietário.

    fd = creat(FILE, 0644);  /* Create file */
    if (fd == -1)
        return;
    if (chown(FILE, UID, -1) < 0) {  /* Change file owner */
      ...
    }

O código pressupõe que o arquivo operado pela chamada para chown() seja igual ao arquivo criado pela chamada para creat(), mas isso não é necessariamente o caso. Como chown() opera em um nome de arquivo e não em um identificador de arquivo, um invasor pode ser capaz de substituir o arquivo por um link para um arquivo que ele não possui. Dessa maneira, a chamada para chown() daria ao invasor a posse sobre o arquivo vinculado.

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().