De forma predeterminada, Castor ejecuta consultas en modo compartido. Como el modo compartido permite acceso de lectura y escritura, no está claro para qué tipo de operación está destinada la consulta. Si el objeto se va a usar en un contexto de solo lectura, el acceso compartido agrega una sobrecarga de rendimiento innecesaria.

Ejemplo 1: el ejemplo siguiente no especifica un modo de consulta.

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

La manipulación de ClassLoader permite a un atacante acceder a la configuración del servidor de aplicaciones subyacente y modificarla. En ciertos servidores de aplicaciones, como Tomcat 8, un atacante puede modificar estas configuraciones para cargar un shell web y ejecutar comandos arbitrarios.

Cuando los datos de una matriz de bytes se convierten en String, no se especifica lo que ocurrirá con los datos que quedan fuera del conjunto de caracteres correspondiente. Esto puede suponer una pérdida de datos o una disminución en el nivel de seguridad cuando se necesitan datos binarios para garantizar que se cumplen las medidas de seguridad apropiadas.

Ejemplo 1: el siguiente código convierte los datos en una cadena para crear un 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
  ...

Si el tamaño del archivo es menor que BUFSIZE, funcionará siempre y cuando la información de myFile se encuentre codificada igual que el conjunto de caracteres predeterminado. Sin embargo, si utiliza una codificación diferente o es un archivo binario, se perderá información. A su vez, esto provocará que el hash de SHA resultante no sea de confianza y que sea más fácil causar conflictos, especialmente si hay algún dato fuera del conjunto de caracteres predeterminado que se represente con el mismo valor, como un signo de interrogación.

No hay forma de especificar qué subproceso se activará con llamadas para notify().

Ejemplo 1: en el código siguiente, notifyJob() llama notify().

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

En es caso, el desarrollador pretende activar el subproceso que llama wait(), pero es posible que notify() notifique un subproceso diferente al previsto.

Si hay varios subprocesos intentando obtener el bloqueo de un recurso, llamar sleep() mientras se mantiene un bloqueo podría causar que todos los demás subprocesos esperen a que el recurso se libere, lo que podría dar lugar a un rendimiento degradado y un interbloqueo.

Ejemplo 1: el código siguiente llama sleep() mientras mantiene un bloqueo.

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

En algún momento de la vida profesional de todos los desarrolladores de Java, surge un problema que parece tan misterioso, impenetrable e inmune a la depuración que parece que no hay otra alternativa que culpar al recopilador de elementos no utilizados. Sobre todo, cuando el error está relacionado con el tiempo y el estado, existe un indicio de prueba empírica que apoya esta teoría: la inserción de una llamada a System.gc() a menudo parece lograr que el problema desaparezca.

En casi todos los casos que hemos visto, la llamada a System.gc() es el método incorrecto. De hecho, llamar a System.gc() puede provocar problemas de rendimiento si se realiza con demasiada frecuencia.

En la mayoría de los casos, una llamada directa a un método run() del objeto Thread indica un error. El programador tenía intención de iniciar un nuevo subproceso de control, pero llamó accidentalmente a run() en lugar de a start(), por lo que el método run() se ejecutará en el subproceso de control del autor de la llamada.

Ejemplo 1: el siguiente extracto de un programa de Java llama por error a run() en lugar de a start().

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

  thr.run();

En la mayoría de los casos, una llamada directa a un método stop() de un objeto Thread es un error. El programador pretende detener la ejecución de un subproceso pero no es consciente de que esa no es la mejor forma de detener un subproceso. La función stop() en Thread produce una excepción ThreadDeath en cualquier lugar del objeto Thread, lo que puede dejar a los objetos en un estado de incoherencia y filtrar recursos. Hace mucho que esta API está en desuso debido a que no es segura por naturaleza.

Ejemplo 1: el siguiente extracto de un programa de Java llama por error a Thread.stop().

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

Al parecer, el programador previó implementar para esta clase la interfaz Cloneable, ya que implementa un método llamado clone(). Sin embargo, la clase no implementa la interfaz Cloneable y el método clone() no se comportará correctamente.

Ejemplo 1: llamar clone() para esta clase dará lugar a una CloneNotSupportedException.

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

Cuando se trata de comparar objetos, los desarrolladores normalmente quieren comparar propiedades de objetos. No obstante, llamar a equals() en una clase (o una superclase/interfaz) que no implemente explícitamente equals() resulta en una llamada al método equals() heredado de java.lang.Object. En lugar de comparar campos de miembros de objetos u otras propiedades, Object.equals() compara dos instancias de objetos para ver si son las mismas. Aunque estos son usos legítimos de Object.equals(), a menudo es indicativo de que el código contiene errores.

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

Cuando una función clone() llama a una función que se puede sobrescribir, puede que el clon se quede en un estado parcialmente inicializado o que se dañe.

Ejemplo 1: la siguiente función clone() llama a un método que se puede sobrescribir.

  ...
  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 la función doSomething() y su clase envolvente no son final, la función se puede sobrescribir, lo que podría dejar al objeto clonado clone en un estado parcialmente inicializado, lo que podría dar lugar a errores o que funcionase en torno a la lógica de forma inesperada.

Cuando se trabaja con primitivos boxed, al comparar la igualdad, debe llamarse al método equals() del primitivo boxed en vez de a los operadores == y !=. La especificación Java establece lo siguiente sobre las conversiones boxing:

"Si el valor p que se usa de referencia (boxed) es un entero literal de tipo entero entre -128 y 127, ambos inclusive; o el literal booleano true o false; o un carácter literal entre '\u0000' y '\u007f', ambos inclusive, a y b son los resultados de cualquier conversión boxing de p. Siempre se da el caso de que a == b."

Esto significa que si se usa un primitivo boxed (distinto de Boolean o Byte), solo se almacenará en la caché o se memorizará un rango de valores. En el caso de un subconjunto de valores, el uso de == o != devolverá el valor correcto. Para los demás valores fuera de dicho subconjunto, se devolverá el resultado de comparar las direcciones de los objetos.

Ejemplo 1: el siguiente ejemplo utiliza operadores de igualdad en primitivos boxed.

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

El código en el Example 1 utiliza primitivos boxed Integer para intentar comparar dos valores int. Si mask0 y mask1 son iguales a 100, entonces mask0 == mask1 devolverá true. Sin embargo, cuando mask0 y mask1 son iguales a 777, mask0 == maske1 devolverá false, ya que dichos valores no están dentro del rango de valores almacenados en la caché para estos primitivos boxed.

Cuando se hace una comparación con NaN, siempre se evalúa como false, excepto en el caso del operador !=, que siempre se evalúa como true, puesto que NaN no está ordenado.

Ejemplo 1: el siguiente ejemplo intenta asegurarse de que una variable no es NaN.

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

Así se intenta comprobar que result no es NaN. Sin embargo, si se utiliza el operador == con NaN siempre da como resultado un valor de false, así que esta comprobación nunca produce la excepción.

Cuando el constructor llama a una función que se puede sobrescribir, el usuario malintencionado puede tener acceso a la referencia de this antes de que el objeto se inicialice por completo, lo que a su vez puede suponer vulnerabilidad.

Ejemplo 1: el siguiente ejemplo llama a un método que se puede sobrescribir.

  ...
  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 la función validateUser y la clase no son final, significa que se pueden sobrescribir y, en consecuencia, al inicializar una variable en la subclase que sobrescribe dicha función, será posible eludir la funcionalidad validateUser. Por ejemplo:

  ...
  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");
      }
    }
  }

El código en el Example 1 imprime "¡Ataque satisfactorio!" porque la clase Attacker sobrescribe la función validateUser(), llamada desde el constructor de la superclase User, y Java comprobará primero la subclase en busca de funciones llamadas desde el constructor.

Un gran número de individuos con talento han dedicado mucho tiempo a sopesar formas de hacer funcionar el bloqueo de doble comprobación para mejorar el rendimiento. Ninguno de ellos lo ha logrado.

Ejemplo 1: a primera vista parece que el siguiente fragmento de código logra la protección de los subprocesos, al mismo tiempo que evita la sincronización innecesaria.

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

El programador desea garantiza que solo se asigne el objeto Fitzer(), pero no desea pagar el coste de la sincronización cada vez que se llame al código. A este giro se le conoce como bloqueo de doble comprobación.

Por desgracia, no funciona y se pueden asignar varios objetos Fitzer(). Consulte la declaración "El bloqueo de doble comprobación está roto" para obtener más información [1].

Los usuarios malintencionados pueden duplicar deliberadamente nombres de clase para hacer que un programa ejecute código malicioso. Por este motivo, los nombres de clase no son buenos identificadores de tipo y no deben usarse como fundamento para otorgar confianza a un objeto determinado.

Ejemplo 1: El siguiente código determina si confiar o no en una entrada de un objeto inputReader en función de su nombre de clase. Si un usuario malintencionado es capaz de suministrar una implementación de inputReader que ejecute comandos maliciosos, el código no puede diferenciar entre las versiones benignas y maliciosas del objeto.

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

Java Language Specification indica que es recomendable que un método finalize() llame a super.finalize() [1].

Ejemplo 1: el siguiente método omite la llamada a super.finalize().

protected void finalize() {
  discardNative();
}

Este campo ha sido anotado con FortifyNonNegative, que se usa para indicar que los valores negativos no están permitidos.

Este programa usa == o != para comparar la igualdad de dos cadenas; es decir, compara la igualdad de dos objetos, no de sus valores. Hay muchas probabilidades de que dos referencias nunca sean iguales.

Ejemplo 1: nunca debe tomarse la siguiente rama.

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

Los operadores == y != solo se comportarán según lo previsto cuando se utilicen para comparar cadenas dentro de objetos iguales. La forma más común para que esto ocurra es que las cadenas sean internas. De este modo, las cadenas se añaden a un grupo de objetos que la clase String mantiene. Una vez que la cadena se interna, todos los usos de dicha cadena emplearán el mismo objeto y los operadores de igualdad se comportarán según lo previsto. Todos los literales de cadena y las constantes con valor de cadena se internan automáticamente. Otras cadenas pueden internarse manualmente llamando String.intern(), lo que devolverá una instancia canónica de la cadena actual, creando una si fuera necesario.

Este campo ha sido anotado con FortifyNonZero, que se usa para indicar que cero no es un valor permitido.