Mesmo que o Castor crie um bloqueio em um objeto, ele não impede que outros threads leiam ou gravem nele. Consultas somente leitura também são cerca de 7 vezes mais rápidas em comparação ao modo compartilhado padrão.

Exemplo 1: O exemplo a seguir especifica o modo de consulta como SHARED, o que permite acesso de leitura e gravação.

results = query.execute(Database.SHARED);

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

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.

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.

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
	}
}

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

Os invasores podem duplicar deliberadamente os nomes das classes para fazer com que um programa execute um código mal-intencionado. Por esse motivo, os nomes das classes não são bons identificadores de tipo e não devem ser usados como base para conceder confiança a determinado objeto.

Exemplo 1: O código a seguir determina se a entrada de um objeto inputReader é confiável com base em seu nome de classe. Se um invasor puder fornecer uma implementação de inputReader que executa comandos mal-intencionados, esse código não poderá diferenciar as versões bem-intencionadas das mal-intencionadas do objeto.

if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
   input = inputReader.getInput();
   ...
}

A Especificação da Linguagem Java afirma que é uma boa prática um método finalize() chamar super.finalize() [1].

Exemplo 1: O seguinte método omite a chamada para super.finalize().

protected void finalize() {
  discardNative();
}

Esse campo foi anotado com FortifyNonNegative, que é usado para indicar que valores negativos não são permitidos.

Esse programa usa == ou != para comparar a igualdade de duas strings, o que compara a igualdade de dois objetos, e não seus valores. São boas as chances de que as duas referências nunca serão iguais.

Exemplo 1: A seguinte ramificação nunca deve ser usada.

  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }

Os operadores == e != apenas se comportarão conforme esperado quando forem usados para comparar strings contidas em objetos que são iguais. A maneira mais comum de isso acontecer é internalizando as strings, processo pelo qual elas são adicionadas a um pool de objetos mantidos pela classe String. Após a internalização de uma string, todas as suas aplicações usarão o mesmo objeto, e os operadores de igualdade terão o comportamento esperado. Todos os literais de string e constantes com valores de string são internalizados automaticamente. Outras strings podem ser internalizadas manualmente chamando String.intern(), o que retornará uma instância canônica da string atual, criando uma se necessário.