Por padrão, o Castor executa consultas no modo compartilhado. Como o modo compartilhado permite o acesso de leitura e gravação, não está claro para que tipo de operação a consulta se destina. Se o objeto for ser usado em um contexto somente leitura, o acesso compartilhado adicionará sobrecarga de desempenho desnecessária.

Exemplo 1: O exemplo a seguir não especifica um modo de consulta.

results = query.execute();    //missing query mode

O armazenamento de um certificado de texto simples em uma configuração ou arquivo de manifesto permite que qualquer pessoa que possa ler o arquivo acesse o recurso protegido por certificado. Os desenvolvedores às vezes acreditam que não podem defender o aplicativo de alguém que tenha acesso à configuração, mas essa atitude torna o trabalho do invasor mais fácil. Boas diretrizes de gerenciamento de certificados exigem que um certificado nunca seja armazenado em texto simples.

A manipulação de ClassLoader permite que um invasor acesse e modifique as configurações do servidor de aplicativos subjacentes. Em certos servidores de aplicativos como o Tomcat 8, um invasor pode ajustar essas configurações para carregar um shell da web e executar comandos arbitrários.

Mecanismos de modelo são usados para renderizar conteúdo usando dados dinâmicos. Esses dados de contexto normalmente são controlados pelo usuário e formatados pelo modelo para gerar páginas da Web, e-mails, entre outros. Os mecanismos de modelo permitem que expressões de linguagem poderosas sejam usadas em modelos para renderizar conteúdo dinâmico, processando os dados de contexto com construções de código como condicionais, loops etc. Se um invasor puder controlar o modelo a ser renderizado, poderá injetar expressões que exponham dados de contexto e executem código mal-intencionado no navegador.

Exemplo 1: O exemplo a seguir mostra como um modelo é recuperado de uma URL e renderiza informações com AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

Nesse caso, $stateParams.expression obterá possivelmente dados controlados pelo usuário e os avaliará como um modelo a ser usado com um contexto especificado. Por sua vez, isso pode permitir que um usuário mal-intencionado execute qualquer código que ele desejar no navegador, recuperando informações sobre o contexto com base no qual ele é executado, encontrando informações adicionais sobre como o aplicativo é criado ou transformando isso em um completo ataque de XSS.

Operações aritméticas não atuarão da mesma maneira em valores boolianos como fariam em valores integrais, o que pode resultar em comportamentos inesperados.

Quando os dados de um array de bytes são convertidos em uma String, não fica claro o que acontecerá com os dados que estiverem fora do conjunto de caracteres aplicável. Isso pode provocar perda de dados ou uma diminuição no nível de segurança quando dados binários são necessários para assegurar que medidas de segurança adequadas sejam seguidas.

Exemplo 1: O código a seguir converte dados em uma String para criar um hash.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

Isso funciona muito bem supondo que o tamanho do arquivo seja menor que BUFSIZE, desde que as informações em myFile sejam codificadas da mesma maneira que o conjunto de caracteres padrão. Porém, se uma codificação diferente estiver em uso, ou se o arquivo for binário, haverá perda de informações. Isso por sua vez fará com que o hash SHA resultante seja menos confiável e pode implicar que colisões podem ser provocadas com muito mais facilidade, especialmente se os dados fora do conjunto de caracteres padrão forem representados pelo mesmo valor, como um ponto de interrogação.

Em algum momento na carreira do todos os desenvolvedores .NET, surge um problema que parece ser tão misterioso, impenetrável e impermeável a depurações que parece não haver nenhuma alternativa a não ser culpar o coletor de lixo. Especialmente quando o bug está relacionado ao tempo e ao estado, pode haver uma pitada de evidência empírica para apoiar essa teoria: inserir uma chamada em GC.Collect() às vezes parece fazer com que o problema desapareça.

Em quase todos os casos que temos visto, chamar GC.Collect() é a coisa errada a se fazer. Na verdade, chamar GC.Collect() pode causar problemas de desempenho isso for feito com demasiada frequência.

Não há como especificar qual thread será ativado por chamadas para notify().

Exemplo 1: No código a seguir, notifyJob() chama notify().

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

Nesse caso, o desenvolvedor tem a intenção de ativar o thread que chama wait(), mas é possível que notify() notifique um thread diferente do pretendido.

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

Em algum momento na carreira do todos os desenvolvedores Java, surge um problema que parece ser tão misterioso, impenetrável e impermeável a depurações que parece não haver nenhuma alternativa a não ser culpar o coletor de lixo. Especialmente quando o bug está relacionado ao tempo e ao estado, pode haver uma pitada de evidência empírica para apoiar essa teoria: inserir uma chamada em System.gc() às vezes parece fazer com que o problema desapareça.

Em quase todos os casos que temos visto, chamar System.gc() é a coisa errada a se fazer. Na verdade, chamar System.gc() pode causar problemas de desempenho isso for feito com demasiada frequência.

Na maioria dos casos, uma chamada direta para o método run() de um objeto Thread é um bug. O programador pretendia iniciar um novo thread de controle, mas acidentalmente chamou run() no lugar de start() e, portanto, o método run() será executado no thread de controle do chamador.

Exemplo 1: O seguinte trecho de um programa Java chama equivocadamente run() em vez de start().

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

Na maioria dos casos, uma chamada direta para o método stop() de um objeto Thread é um bug. O programador pretendia parar a execução de um thread, mas não sabia que esta não é uma maneira adequada de fazer isso. A função stop() dentro de Thread causa uma exceção ThreadDeath em qualquer lugar dentro do objeto Thread, provavelmente deixando objetos em um estado inconsistente e possivelmente deixando vazar recursos. Como essa API é inerentemente insegura, seu uso foi preterido há muito tempo.

Exemplo 1: O seguinte trecho de um programa Java chama equivocadamente Thread.stop().

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

Parece que o programador pretendia que essa classe implementasse a interface Cloneable, pois ela implementa um método denominado clone(). No entanto, a classe não implementa a interface Cloneable, e o método clone() não se comportará corretamente.

Exemplo 1: Chamar clone() para essa chamada resultará em uma CloneNotSupportedException.

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

Ao comparar objetos, os desenvolvedores geralmente desejam comparar propriedades de objetos. No entanto, chamar equals() em uma classe (ou qualquer superclasse/interface) que não implemente equals() explicitamente resulta em uma chamada para o método equals() herdada de java.lang.Object. Em vez de comparar campos membros de objetos ou outras propriedades, o Object.equals() compara duas instâncias de objeto para ver se elas são iguais. Embora existam usos legítimos de Object.equals(), muitas vezes isso é uma indicação de um código com bug.

Exemplo 1:

public class AccountGroup
{
	private int gid;

	public int getGid()
	{
		return gid;
	}

	public void setGid(int newGid)
	{
		gid = newGid;
	}
}
...
public class CompareGroup
{
	public boolean compareGroups(AccountGroup group1, AccountGroup group2)
	{
		return group1.equals(group2);   //equals() is not implemented in AccountGroup
	}
}

A interface ICloneable não garante uma clonagem profunda. As classes que a implementam podem não apresentar o comportamento esperado ao serem clonadas. Classes que implementam ICloneable e executam apenas uma clonagem superficial (cópias apenas do objeto, o que inclui referências existentes a outros objetos) podem resultar em um comportamento inesperado. Como a clonagem profunda (cópias do objeto e de todos os objetos referenciados) é normalmente o comportamento assumida de um método de clone, o uso da interface ICloneable é propenso a erros e deve ser evitado.

Quando uma função clone() chama uma função substituível, ela pode fazer com que o clone seja deixado em um estado parcialmente inicializado ou se torne corrompido.

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

  ...
  class User implements Cloneable {
    private String username;
    private boolean valid;
    public Object clone() throws CloneNotSupportedException {
      final User clone = (User) super.clone();
      clone.doSomething();
      return clone;
    }
    public void doSomething(){
      ...
    }
  }

Como a função doSomething() e a sua classe delimitadora não são final, significa que a função pode ser substituída, o que pode deixar o objeto clone clonado em um estado parcialmente inicializado, capaz de provocar erros, se não estiver trabalhando em torno da lógica de uma forma inesperada.

Ao lidar com primitivas encaixotadas, ao comparar a igualdade, o método equals() da primitiva encaixotada deve ser chamado em vez dos operadores == e !=. A Especificação Java declara o seguinte sobre conversões de encaixotamento:

"Se o valor de p que está sendo encaixotado for um número inteiro literal do tipo int entre -128 e 127, inclusive, ou um booliano literal true ou false, ou um caractere literal entre '\u0000' e '\u007f', inclusive, deixe que a e b sejam os resultados de quaisquer duas conversões de encaixotamento de p. Em todos os casos, a == b."

Isso significa que, se uma primitiva encaixotada for usada (diferente de Boolean ou Byte), apenas uma faixa de valores será armazenada em cache ou memorizada. Para um subconjunto de valores, o uso de == ou != retornará o valor correto. Para todos os outros valores fora desse subconjunto, isso retornará o resultado da comparação dos endereços de objetos.

Exemplo 1: O exemplo a seguir usa operadores de igualdade em primitivas encaixotadas.

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

O código no Example 1 usa primitivas encaixotadas Integer para tentar comparar dois valores int. Se mask0 e mask1 forem ambos iguais a 100, mask0 == mask1 retornará true. No entanto, quando mask0 e mask1 forem ambos iguais a 777, mask0 == maske1 agora retornará false, pois esses valores não estão dentro do intervalo de valores armazenados em cache para essas primitivas encaixotadas.

Quando é feita uma comparação com NaN, ela é sempre avaliada como false, exceto para o operador !=, que sempre é avaliado como true, já que NaN não está ordenado.

Exemplo 1: O exemplo a seguir tenta garantir que uma variável não é NaN.

  ...
  if (result == Double.NaN){
    //something went wrong
    throw new RuntimeException("Something went wrong, NaN found");
  }
  ...

Isso tenta verificar se result não é NaN, mas o uso do operador == com NaN sempre resulta em um valor de false, e, portanto, essa verificação nunca lançará a exceção.

Quando um construtor chama uma função substituível, isso pode permitir que um invasor acesse a referência this antes que o objeto seja totalmente inicializado, o que, por sua vez, pode provocar uma vulnerabilidade.

Exemplo 1: O exemplo a seguir chama um método que pode ser substituído.

  ...
  class User {
    private String username;
    private boolean valid;
    public User(String username, String password){
      this.username = username;
      this.valid = validateUser(username, password);
    }
    public boolean validateUser(String username, String password){
      //validate user is real and can authenticate
      ...
    }
    public final boolean isValid(){
      return valid;
    }
  }

Como a função validateUser e a classe não são final, isso significa que elas podem ser substituídas e, dessa forma, inicializar uma variável para a subclasse que substitui essa função possibilitaria o desvio da funcionalidade validateUser. Por exemplo:

  ...
  class Attacker extends User{
    public Attacker(String username, String password){
      super(username, password);
    }
    public boolean validateUser(String username, String password){
      return true;
    }
  }
  ...
  class MainClass{
    public static void main(String[] args){
      User hacker = new Attacker("Evil", "Hacker");
      if (hacker.isValid()){
        System.out.println("Attack successful!");
      }else{
        System.out.println("Attack failed");
      }
    }
  }

O código no Example 1 imprime "Attack successful!", uma vez que a classe Attacker substitui a função validateUser() que é chamada a partir do construtor da superclasse User, e o Java primeiro examinará a subclasse em busca de funções chamadas a partir desse construtor.

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].