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.

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.

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

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.

La especificación de Enterprise JavaBeans exige que todos los proveedores de bean sigan una serie de instrucciones de programación diseñadas para garantizar que el bean sea portátil y se comporte de forma coherente en cualquier contenedor EJB [1].

En este caso, el programa infringe la siguiente instrucción EJB:

"Enterprise bean no debe intentar crear un cargador de clases, establecer el cargador de clases de contexto, establecer el administrador de seguridad, crear un nuevo administrador de seguridad, detener el JVM ni cambiar los flujos de entrada, salida y error".

Se trata de un requisito que la especificación justifica de la siguiente forma:

"Estas funciones están reservadas para el contenedor de Enterprise Beans. Permitir a enterprise bean usar estas funciones podría comprometer la seguridad y reducir la capacidad del contenedor de administrar adecuadamente el entorno de tiempo de ejecución".

El comportamiento de las funciones de esta categoría varía en función del sistema operativo y, a veces, entre versiones de los mismos. Entre las diferencias de implementación, se incluyen:

- Ligeras diferencias en la forma en que se interpretan los comandos, lo que da lugar a resultados incoherentes.

- Algunas implementaciones de la función conllevan considerables riesgos de seguridad.

- Es posible que la función no se defina en todas las plataformas.

Cada sistema operativo utiliza caracteres diferentes como separadores de archivos. Por ejemplo, los sistemas Microsoft Windows utilizan "\", mientras que los sistemas UNIX utilizan "/". Cuando las aplicaciones tienen que ejecutarse en distintas plataformas, el uso de separadores de archivos codificados puede provocar la ejecución incorrecta de la lógica de la aplicación y, posiblemente, una denegación de servicio.

Ejemplo 1: el siguiente código utiliza un separador de archivos codificados para abrir un archivo:

...
File file = new File(directoryName + "\\" + fileName);
...

Es necesario especificar una configuración regional concreta al comparar datos que depende de ella.

Ejemplo 1: el siguiente ejemplo trata de llevar a cabo la validación para determinar si la entrada del usuario incluye una etiqueta<script>.

  ...
  public String tagProcessor(String tag){
    if (tag.toUpperCase().equals("SCRIPT")){
      return null;
    }
    //does not contain SCRIPT tag, keep processing input
    ...
  }
  ...

El problema con el Example 1 es que java.lang.String.toUpperCase(), cuando se usa sin configuración regional, emplea las reglas de la configuración regional predeterminada. El hecho de utilizar la configuración regional turca "title".toUpperCase() devuelve "T\u0130TLE", donde "\u0130" es el carácter "I LATINA MAYÚSCULA CON PUNTO". Esto puede dar lugar a resultados inesperados, como en el Example 1, en el que se impide que la validación capture la palabra "script", lo que puede dar lugar a una potencial vulnerabilidad de scripts entre sitios.

Los sistemas SAP están diseñados para ser independientes de la plataforma. Open SQL, el dialecto SQL portátil de SAP, hace que las aplicaciones sean independientes de un controlador JDBC de un determinado proveedor de base de datos. El uso de Open SQL elimina las complejidades de la base de datos subyacente y proporciona una interfaz común a programas de aplicaciones para todas las operaciones de base de datos. Sin embargo, SQL nativo es específico de la base de datos subyacente y, por lo tanto, su uso en otras plataformas podría provocar a una ejecución incorrecta de la lógica de las aplicaciones y conducir potencialmente a una denegación de servicio.
Ejemplo 1: el siguiente código usa SQL nativo:

...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;

String mssOnlyStmt = "...";
// variant 1
  PreparedStatement ps =
  NativeSQLAccess.prepareNativeStatement(
    conn, mssOnlyStmt);
  . . .
// variant 2
  Statement stmt =
  NativeSQLAccess.createNativeStatement(conn);
  int result = stmt.execute(mssOnlyStmt);
  . . .
// variant 3
  CallableStatement cs =
  NativeSQLAccess.prepareNativeCall(
  conn, mssOnlyStmt);
  . . .