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

El almacenamiento de un certificado de texto sin formato en una configuración o un archivo de manifiesto permite que cualquier persona que pueda leer el archivo acceda al recurso protegido por certificado. Los desarrolladores a veces creen que no pueden proteger la aplicación de alguien que tenga acceso a la configuración, pero esta actitud facilita el trabajo de un atacante. Las buenas pautas de administración de certificados requieren que un certificado nunca se almacene en texto sin formato.

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.

Los motores de plantillas se usan para procesar contenido mediante datos dinámicos. El usuario suele controlar estos datos de contexto, a los que se les da formato mediante una plantilla para generar páginas web, correos electrónicos, etc. Los motores de plantillas permiten usar potentes expresiones de lenguaje en plantillas para procesar contenido dinámico; para ello, los datos de contexto se procesan con construcciones de codificación, como condicionales, bucles, etc. Si un atacante controla la plantilla que se desea procesar, puede inyectar expresiones que expongan los datos de contexto y ejecuten comandos arbitrarios en el explorador.

Ejemplo 1: en el ejemplo siguiente se muestra cómo recuperar una plantilla de una dirección URL y cómo se representa la información con AngularJS.

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

En este caso, $stateParams.expression tomará datos potencialmente controlados por el usuario y los evaluará como una plantilla para utilizarlos con un contexto especificado. Esto, a su vez, puede permitir a un usuario malintencionado ejecutar cualquier código que desee en el explorador, recuperando información sobre el contexto en el que se ejecute, buscando información adicional sobre cómo se crea la aplicación o convirtiéndolo en un auténtico ataque XSS.

Las operaciones aritméticas no actúan del mismo modo en valores booleanos a como lo harían en valores integrales, lo que podría ocasionar un comportamiento inesperado.

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.

En algún momento de la carrera profesional del desarrollador de .NET, surge un problema para parece tan misterioso, impenetrable e inmune a la depuración que no queda otra opción 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 GC.Collect() a menudo parece lograr que el problema desaparezca.

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

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

La interfaz ICloneable no garantiza una clonación profunda; es posible que las clases que la implementan no se comporten en la forma prevista cuando se clonen. Las clases que implementan ICloneable y realizan solo clonaciones superficiales (se copia solo el objeto, lo que incluye las referencias a otros objetos) pueden provocar un comportamiento inesperado. Como la clonación profunda (se copia el objeto y todos los objetos de referencia) suele ser normalmente el comportamiento previsto de un método de clonación, el uso de la interfaz ICloneable es propenso a errores, por lo que debe evitarse.

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