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.

En PL/SQL, el valor de NULL es indeterminado. No es igual a ningún valor, ni incluso a otro valor NULL. Además, un valor null nunca es igual a otro valor.

Ejemplo 1: la siguiente instrucción siempre será falsa.

checkNull BOOLEAN := x = NULL;

Ejemplo 2: la siguiente instrucción siempre será falsa.

checkNotNull BOOLEAN := x != NULL;

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.

Después de que un subproceso señale otros a la espera de una exclusión mutua, este debe desbloquear la exclusión mutua llamando pthread_mutex_unlock() antes de que otro subproceso empiece a ejecutarse. Si el subproceso que señala no puede desbloquear la exclusión mutua, la llamada pthread_cond_wait() del segundo subproceso no volverá y el subproceso no se ejecutará.

Ejemplo 1: el código siguiente señala otro subproceso a la espera de una exclusión mutua llamando pthread_cond_signal(), pero no puede desbloquear la exclusión mutua en la que espera el otro subproceso.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

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

Esta expresión siempre será no nula porque hace referencia a un puntero de función más que al valor devuelto de la función.

Ejemplo 1: la condicional siguiente nunca se disparará. El predicado getChunk == NULL siempre será falso porque getChunk es el nombre de una función definida en el programa.

  if (getChunk == NULL)
    return ERR;

Como las variables locales están asignadas en la pila, cuando un programa devuelve un puntero a una variable local, se devuelve una dirección de pila. Es probable que la siguiente llamada de función vuelva a utilizar esta misma dirección de pila y, por lo tanto, sobrescriba el valor del puntero, que ya no corresponde a la misma variable porque el marco de pila de una función queda invalidado cuando vuelve. En el mejor de los casos, esto provocará que el valor del puntero cambie de forma inesperada. En muchos casos provoca el bloqueo del programa la próxima vez que se desreferencia el puntero. El problema puede ser difícil de depurar porque la causa del mismo a menudo está muy alejada del síntoma.

Ejemplo 1: la función siguiente devuelve una dirección de pila.

char* getName() {
  char name[STR_MAX];
  fillInName(name);
  return name;
}

Por definición, no es posible anular los métodos estáticos, ya que pertenecen a la clase más que a una instancia de la clase. Sin embargo, hay casos en los que parece que el método estático se anuló en una subclase, lo que podría provocar confusión y que se llamase a la versión incorrecta del método.

Ejemplo 1: el siguiente ejemplo intenta definir una API para autenticar a los usuarios.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

A primera vista, parece que el código está bien. Sin embargo, como estamos llamando al método getAccessLevel() en la instancia user y no en las clases User o RegularUser, la condición siempre devolverá true y se llevará a cabo la operación restringida aunque se utilice instanceof para entrar en esta parte del bloque if/else.

Corrección del código: se producen problemas de firma incorrecta del método serializable cuando una clase serializable crea una función de serialización o deserialización pero no sigue las firmas correctas:

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

Una desviación de las firmas del método que requiere la serialización puede provocar que nunca se llame al método durante la serialización o deserialización. Esto supondría una serialización o deserialización incompleta o podría permitir que un código que no es de confianza obtenga acceso a los objetos.
En el caso de que se produzcan excepciones no arrojadas, puede significar que la serialización o deserialización está fallando y bloqueando la aplicación o que podría incluso fallar discretamente. En tal caso, los objetos se crearían correctamente solo en parte y se producirían errores muy difíciles de depurar. El autor de la llamada deberá filtrar estas excepciones de manera que la serialización o deserialización incorrectas puedan tratarse correctamente sin la presencia de bloqueos o de objetos creados parcialmente.

La especificación de serialización de objetos Java permite que los desarrolladores definan manualmente los campos serializables para una clase en la matriz serialPersistentFields. Esta característica solo funcionará si serialPersistentFields se declara como private, static y final.

Ejemplo 1: La siguiente declaración de serialPersistentFields no se utilizará para definir campos Serializable porque no es private, static y final.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

Llamar a Object.equals() en una matriz es casi siempre un error, ya que comprobará la igualdad de las direcciones de las matrices, en vez de la igualdad de los elementos de las matrices, y debería reemplazarse por java.util.Arrays.equals().

Ejemplo 1: el siguiente ejemplo intenta comprobar dos matrices utilizando la función Object.equals().

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

Esto casi siempre resultará en código que nunca se ejecuta, a menos que en algún momento se asigne una matriz a otra.

Algunas familias de funciones se implementan como funciones en algunas plataformas y como macros en otras. Si las funciones se basan en un recurso compartido que se mantiene de forma interna en lugar de transferirse cuando se invoca, deben usarse en el mismo ámbito del programa, porque de otro modo el recurso compartido será inaccesible.

Ejemplo 1: el código siguiente usa pthread_cleanup_push() para insertar la función routine en las devoluciones y la pila de limpieza del subproceso de llamada. Como pthread_cleanup_push() y su función asociada pthread_cleanup_pop() se implementan como macros en las plataformas que no son IBM AIX, la estructura de datos creada por pthread_cleanup_push() no será accesible para las subsiguientes llamadas a pthread_cleanup_pop(). El código no se compilará o se comportará incorrectamente en tiempo de ejecución en todas las plataformas donde estas funciones se implementen como macros.

void helper() {
   ...
   pthread_cleanup_push (routine, arg);
}

No desasigne de forma explícita la memoria de pila. Una función que defina el búfer de una pila desasignará automáticamente el búfer cuando la función vuelva.
Ejemplo 1:

void clean_up()
{
    char tmp[256];
    ...
    free(tmp);
    return;
}

La liberación explícita de la memoria de pila puede dañar las estructuras de datos de asignación de memoria. Puede llevar a la finalización anómala del programa o dañar más datos.

El nombre de este método es similar al nombre del método habitual de Java, pero se ha escrito incorrectamente o la lista de argumentos provoca que no se reemplace al método previsto.

Ejemplo 1: el siguiente método está diseñado para reemplazar Object.equals():

public boolean equals(Object obj1, Object obj2) {
  ...
}

Como Object.equals() toma solo un argumento, el método en el Example 1 no se llama nunca.

El tiempo de ejecución de .NET permite la serialización de cualquier objeto que declare el atributo [Serializable]. Si la clase se puede serializar mediante los métodos de serialización predeterminados definidos por .NET Framework, esto es necesario y suficiente para que el objeto se serialice correctamente. Si la clase requiere métodos de serialización personalizados, debe implementar también la interfaz ISerializable. Sin embargo, la clase debe declarar aún el atributo [Serializable].

Ejemplo 1: la clase CustomStorage implementa la interfaz ISerializable. Sin embargo, debido a que no puede declarar el atributo [Serializable], no se serializará.

public class CustomStorage: ISerializable {
	...
}

Enviar una HttpServletRequest, redirigir una HttpServletResponse o vaciar el flujo de salida del servlet provoca la confirmación del flujo asociado. Todo restablecimiento de búfer o confirmación de flujo, como los vaciados o los redireccionamientos adicionales, provocarán una IllegalStateExceptions.

Además, los servlets de Java permiten que los datos se escriban en el flujo de respuesta empleando ServletOutputStream o PrintWriter, pero no ambos. Llamar getWriter() después de haber llamado getOutputStream(), o viceversa, también provocará una IllegalStateException.



En tiempo de ejecución, una IllegalStateException impide que el controlador de respuesta se ejecute hasta la finalización, entregando la respuesta de forma eficaz. Esto puede causar inestabilidad en el servidor, señal de que un servlet se ha implementado incorrectamente.

Ejemplo 1: el código siguiente redirige la respuesta del servlet después de que su búfer de flujo de salida se haya vaciado.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

Ejemplo 2: por otra parte, el código siguiente intenta escribir en el búfer de PrintWriter y vaciarlo después de que la solicitud se haya enviado.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

En la mayoría de los casos, la configuración del encabezado Content-Length de una solicitud indica que el desarrollador está interesado en
comunicar la longitud de los datos POST enviados al servidor. No obstante, este encabezado debe ser 0 o un
número entero positivo.

Ejemplo 1: el siguiente código establecerá un encabezado Content-Length incorrecto.

  URL url = new URL("http://www.example.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

La serialización de las clases internas supone la serialización de la clase externa y puede que se filtre información o se produzca un error en el tiempo de ejecución si no es posible serializar la clase externa. Además, la serialización de las clases internas puede causar dependencias de la plataforma, ya que el compilador Java crea campos sintéticos para implementar las clases internas, pero dichos campos dependen de la implementación y varían en función del compilador.

Ejemplo 1: el siguiente código permite la serialización de una clase interna.

  ...
  class User implements Serializable {
    private int accessLevel;
    class Registrator implements Serializable {
      ...
    }
  }

En el Example 1, cuando se serializa la clase interna Registrator, también se serializa el campo accessLevel de la clase externa User.