When data from a byte array is converted into a String, it is unspecified what will happen to any data that is outside of the applicable character set. This can lead to data being lost, or a decrease in the level of security when binary data is needed to ensure proper security measures are followed.

Example 1: The following code converts data into a String in order to create a 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
  ...

Assuming the size of the file is less than BUFSIZE, this works fine as long as the information in myFile is encoded the same as the default character set, however if it's using a different encoding, or is a binary file, it will lose information. This in turn will cause the resulting SHA hash to be less reliable, and could mean it's far easier to cause collisions, especially if any data outside of the default character set is represented by the same value, such as a question mark.

When a comparison is made to NaN it is always evaluated as false, except for the != operator, which always evaluates to true since NaN is unordered.

Example 1: The following tries to make sure a variable is not NaN.

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

This attempts to verify that result is not NaN, however using the operator == with NaN always results in a value of false, so this check will never throw the exception.

Attackers can deliberately duplicate class names in order to cause a program to execute malicious code. For this reason, class names are not good type identifiers and should not be used as the basis for granting trust to a given object.

Example 1: The following code determines whether to trust input from an inputReader object based on its class name. If an attacker can supply an implementation of inputReader that executes malicious commands, this code cannot differentiate the benign and malicious versions of the object.

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

Static methods cannot be overridden by definition, since they belong to the class rather than an instance of the class. Although there are cases where it looks like a static method has been overridden in a subclass, which may cause confusion and can lead to the incorrect version of the method being called.

Example 1: The following tries to define an API for authenticating users.

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

At first glance, this code looks fine. However, since we are calling the method getAccessLevel() against the instance user and not against the classes User or RegularUser, it will mean that this condition will always return true, and the restricted operation will be performed even though instanceof was used in order to get into this part of the if/else block.

The behavior of functions in this category varies by operating system, and at times, even by operating system version. Implementation differences can include:

- Slight differences in the way parameters are interpreted leading to inconsistent results.

- Some implementations of the function carry significant security risks.

- The function might not be defined on all platforms.

Different operating systems use different characters as file separators. For example, Microsoft Windows systems use "\", while UNIX systems use "/". When applications have to run on different platforms, the use of hardcoded file separators can lead to incorrect execution of application logic and potentially a denial of service.

Example 1: The following code uses a hardcoded file separator to open a file:

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

When comparing data that may be locale-dependent, an appropriate locale should be specified.

Example 1: The following example tries to perform validation to determine if user input includes a <script> tag.

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

The problem with Example 1 is that java.lang.String.toUpperCase() when used without a locale uses the rules of the default locale. Using the Turkish locale "title".toUpperCase() returns "T\u0130TLE", where "\u0130" is the "LATIN CAPITAL LETTER I WITH DOT ABOVE" character. This can lead to unexpected results, such as in Example 1 where this will prevent the word "script" from being caught by this validation, potentially leading to a Cross-Site Scripting vulnerability.

SAP systems are designed to be platform independent. Open SQL, SAP's portable SQL dialect, makes applications independent of a specific database vendor's JDBC driver. Usage of Open SQL abstracts the intricacies of the underlying database, and provides a common interface to application programs for all database operations. However, native SQL is specific to the underlying database and therefore its usage on other platforms may lead to incorrect execution of application logic and potentially a denial of service.
Example 1: The following code uses native SQL:

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