Durante a desserialização, readObject() age como um construtor e, portanto, a inicialização do objeto só estará concluída quando essa função terminar. Portanto, quando uma função readObject() de uma classe Serializable chama uma função substituível, isso pode fornecer ao método de substituição o acesso necessário ao estado do objeto antes que ele seja totalmente inicializado.

Exemplo 1: A função readObject() a seguir chama um método que pode ser substituído.

  ...
  private void readObject(final ObjectInputStream ois) throws IOException, ClassNotFoundException {
    checkStream(ois);
    ois.defaultReadObject();
  }

  public void checkStream(ObjectInputStream stream){
    ...
  }

Como a função checkStream() e sua classe delimitadora não são final e públicas, isso implica que a função pode ser substituída, o que pode significar que um invasor pode substituir a função checkStream() a fim de obter acesso ao objeto durante a desserialização.

Retornar uma variável de lista private readonly de uma propriedade somente "getter" permite que o código de chamada modifique o conteúdo da lista, fornecendo a ela eficazmente acesso de gravação e contrariando as intenções do programador que a tornou private readonly.

Exemplo 1: O código a seguir contém uma lista _item, que é declarada como private readonly.

       class Order
      {
          private readonly List<string> _item = new List<string>();
          public IEnumerable<string> Item { get { return _item; } }
          
          public Order()
          {
              /*class initialize            */
          }

          /*some important function......*/
      }
    

Um ataque de reentrada ocorre quando um contrato mal-intencionado faz uma chamada de volta para o contrato de chamada antes que a primeira invocação seja concluída. Isso acontece quando o contrato vulnerável expõe uma função que interage com contratos externos antes de executar localmente o efeito da chamada atual. Isso pode fazer com que o contrato externo assuma o controle do fluxo de interação.

Se um contrato mal-intencionado chamar a função exposta de uma vítima que interage de forma insegura com o contrato de chamada, o contrato de ataque receberá e processará a interação (por meio de uma função de fallback, por exemplo) e imediatamente chamará novamente a função exposta da vítima para entrar em um loop call-interact-call. Esse estado recursivo impede que qualquer outro código da vítima seja executado e pode levar à drenagem parcial ou total de ativos ou valores, dependendo da natureza da interação.

O padrão Checks-Effects-Interaction é comumente usado em contratos inteligentes para evitar lógica incorreta. O padrão determina que o código primeiro verifique todas as condições necessárias, depois execute a alteração de estado relacionada (o efeito) e, por fim, interaja com o contrato externo em relação a esse efeito.

Exemplo 1: O exemplo a seguir permite um ataque de reentrada ao executar uma verificação, uma interação e, em seguida, um efeito, não aderindo ao padrão Checks-Effects-Interaction.

O código:

1. Verifica o saldo do remetente (Checks, Verificações).
2. Envia Ether para o chamador via msg.sender.call.value (Interaction, Interação).
3. Realiza uma mudança de estado diminuindo o saldo do remetente (Effects, Efeitos).

function withdraw(uint amount) public{
    if (credit[msg.sender] >= amount) {
        require(msg.sender.call.value(amount)());
        credit[msg.sender]-=amount;
    }
}

O código em Example 1 quebra o padrão Checks-Effects-Interaction executando Checks-Interaction-Effects. Isso poderá levar à reentrada se um contrato inteligente de ataque receber o Ether em uma função de fallback e imediatamente chamar de volta withdraw, criando uma situação recursiva em que o Ether é drenado porque a linha de código que diminui o equilíbrio (também conhecido como Efeito) nunca é executada.

O uso da recursão é um elemento básico para criar e gerenciar estruturas de dados vinculadas. A recursão também correrá o risco de processar indefinidamente se os dados incorporarem um link circular, que, por sua vez, esgotará a pilha e travará o programa.

Exemplo 1: O trecho de código a seguir demonstra essa vulnerabilidade usando o Apache Log4j2.

Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");

child.addParents(parent);
parent.addParents(child); 
        
String toInfinity = child.toString();

Quando o filho chama toString(), que inclui um método de processamento recursivo, ele aciona uma exceção de estouro de pilha (exaustão de pilha). Essa exceção ocorre devido ao link circular entre filho e pai.

Para comparar um valor de ponto flutuante com um objeto String, ele primeiro deve ser transformado em um objeto String, o que normalmente é feito usando uma função como Double.toString(). Dependendo do tipo e do valor da variável de ponto flutuante, quando convertida em um objeto String, ela pode ser "NaN", "Infinity", "-Infinity", ter uma certa quantidade de casas decimais à esquerda contendo zeros ou incluir uma campo de expoente. Se convertida em uma String hexadecimal, a representação também poderá ser consideravelmente diferente.

Exemplo 1: O exemplo a seguir compara a variável de ponto flutuante com uma String.

  ...
  int initialNum = 1;
  ...
  String resultString = Double.valueOf(initialNum/10000.0).toString();
  if (s.equals("0.0001")){
    //do something
    ...
  }
  ...

O Banco de dados SQL do Windows Azure dá suporte apenas à autenticação do SQL Server. A autenticação do Windows (segurança integrada) não tem suporte. Os usuários devem fornecer credenciais (login e senha) cada vez que se conectarem ao banco de dados SQL do Windows Azure. De acordo com as diretrizes e limitações gerais do banco de dados SQL do Microsoft Windows Azure, estes nomes de contas não estão disponíveis: admin, administrador, convidado, raiz, sa.

O código circundante torna impossível que essa instrução seja executada.

Exemplo: A condição para a segunda instrução if é impossível de atender. Ela requer que a variável s seja não nula, embora no único caminho em que s pode receber um valor não nulo exista uma instrução return.

String s = null;

if (b) {
   s = "Yes";
   return;
}

if (s != null) {
   Dead();
}