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.

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.

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

Métodos estáticos não podem ser substituídos por definição, uma vez que pertencem à classe e não a uma instância da classe. Mesmo assim, existem casos em que parece que um método estático foi substituído em uma subclasse, o que pode causar confusão e fazer com que uma versão incorreta do método seja chamada.

Exemplo 1: O exemplo a seguir tenta definir uma API para a autenticação de usuários.

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

À primeira vista, esse código parece bom. No entanto, como estamos chamando o método getAccessLevel() em relação à instância user, e não contra as classes User ou RegularUser, isso significa que essa condição sempre retornará true e a operação restrita será realizada mesmo que instanceof tenha sido usado para entrar nessa parte do bloco if/else.

O comportamento de funções nessa categoria varia de acordo com o sistema operacional e, às vezes, até mesmo com a versão do sistema operacional. Diferenças de implementação podem incluir:

- Pequenas diferenças em como os parâmetros são interpretados, provocando resultados inconsistentes.

- Algumas implementações da função contêm riscos de segurança significativos.

- A função não pode ser definida em todas as plataformas.

Diferentes sistemas operacionais usam diferentes caracteres como separadores de arquivo. Por exemplo, os sistemas Microsoft Windows usam "\", enquanto os sistemas UNIX usam "/". Quando os aplicativos precisam ser executados em plataformas diferentes, o uso de separadores de arquivo inseridos em código fixo pode resultar na execução incorreta da lógica do aplicativo e, potencialmente, em uma negação de serviço.

Exemplo 1: O seguinte código usa um separador de arquivo inserido em código fixo para abrir um arquivo:

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

Ao comparar dados que pode ser dependentes de localidade, uma localidade apropriada deve ser especificada.

Exemplo 1: O exemplo a seguir tenta realizar uma validação para determinar se a entrada do usuário inclui uma tag <script>.

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

O problema com o Example 1 é que java.lang.String.toUpperCase(), quando usado sem uma localidade, aplica as regras da localidade padrão. O uso da localidade turca "title".toUpperCase() retorna "T\u0130TLE", onde "\u0130" é o caractere "LATIN CAPITAL LETTER I WITH DOT ABOVE". Isso pode provocar resultados inesperados, como no Example 1, em que isso impedirá que a palavra "script" seja capturada por essa validação, podendo causar uma vulnerabilidade de Cross-Site Scripting.

Os sistemas SAP são projetados para serem independentes de plataforma. Open SQL, o dialeto SQL portátil do SAP, torna os aplicativos independentes do driver JDBC de um fornecedor de banco de dados específico. A utilização do Open SQL abstrai os meandros do banco de dados subjacente e fornece uma interface comum para programas de aplicativo para todas as operações de banco de dados. No entanto, o SQL nativo é específico do banco de dados subjacente e, portanto, o uso dele em outras plataformas pode provocar a execução incorreta da lógica do aplicativo e, potencialmente, uma negação de serviço.
Exemplo 1: O seguinte 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);
  . . .