バイト配列からのデータが String に変換された場合、適用可能な文字セットに含まれないデータに何が起こるかは不明です。これによって、データが失われる可能性があります。また、適切なセキュリティ体制を保証するためにバイナリ データが必要な場合は、セキュリティ レベルの低下につながります。

例 1: 次のコードは、ハッシュを生成するためにデータを文字列に変換します。

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

ファイルのサイズが BUFSIZE より小さいと仮定すると、myFile の情報がデフォルトの文字セットと同様にエンコードされている限り問題はありません。ただし、別のエンコーディングが使用されていたり、ファイルがバイナリ ファイルである場合は、情報を失います。その結果、生成された SHA ハッシュの信頼性が損なわれ、特にデフォルトの文字セットに含まれないデータが疑問符などの同じ値で表されている場合、衝突が発生しやすくなった可能性があることを意味します。

NaN と比較した場合、常に false と評価されます。例外は != 演算子で、NaN は非順序型であるため常に true と評価されます。

例 1: 次では、変数が NaN ではないことを確認しています。

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

ここでは、result が NaN ではないことの検証を試みています。しかし、NaN に演算子 == を使用すると、常に結果は false の値になり、このチェックで例外がスローされることはありません。

攻撃者は、プログラムで悪意あるコードが実行されるようにするために、クラス名を故意に複製する可能性があります。この理由から、クラス名はタイプを表す識別子として適切ではないため、特定のオブジェクトを信頼する基準として使用しないでください。

例 1: 次のコードは、そのクラス名を基準にして inputReader オブジェクトからの入力を信頼するかどうかを決定しています。攻撃者が悪意あるコマンドを実行する inputReader の実装を提供できる場合、このコードはオブジェクトが無害であるか悪意あるものであるかを区別することができなくなります。

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

静的メソッドは、クラスのインスタンスではなくクラスに属しているため、定義で上書きすることはできません。静的メソッドがサブクラスでオーバーライドされているように見える場合もあるため、混乱を引き起こし、誤ったバージョンのメソッドがコールされることもあります。

例 1: 次の例では、ユーザーを認証する API を定義しています。

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

このコードは、一見問題がないように見えます。しかし、メソッド getAccessLevel() をインスタンス user にコールしているのであって、クラス User や RegularUser にコールしているのではないため、この場合は常に true が返され、instanceof が使用される場合でも、if/else ブロックのこの部分に到達するために操作が制限されます。

このカテゴリの関数は、オペレーティングシステムにより、また場合によってはオペレーティングシステムのバージョンによっても動作が変わります。実装の相違には、以下のものがあります。

- パラメーターの解釈方法のわずかな相違。結果の不整合をもたらします。

- 関数の一部の実装。深刻なセキュリティリスクをもたらします。

- 関数が定義されていないプラットフォームがある可能性。

オペレーティングシステムが異なっていると、ファイル区切り文字として使用される文字も異なります。たとえば、Microsoft Windows システムでは "\" が使用されますが、UNIX システムでは "/" が使用されます。複数の異なるプラットフォーム上でアプリケーションを実行しなければならない場合、ハードコーディングされたファイル区切り文字を使用すると、アプリケーションロジックが適切に実行されず、Denial of Service が引き起こされる可能性があります。

例 1: 次のコードは、ハードコーディングされたファイル区切り文字を使用してファイルを開きます。

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

ロケール依存のデータを比較する場合、適切なロケールを指定する必要があります。

例 1: 次の例では、ユーザー入力に <script> タグが含まれているかを判定するための検証を実行しています。

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

Example 1 の問題は、ロケールを指定せずに java.lang.String.toUpperCase() を使用した場合、デフォルトのロケールを使用するルールが適用されることです。トルコ語ロケールを使用すると "title".toUpperCase() は "T\u0130TLE" を返します。ここで "\u0130" は、"上に点が付いたラテン語の大文字 I" になります。これは、Example 1 のように "script" という単語が検証でキャッチされないなどの予期しない結果につながる場合があり、クロスサイト スクリプティングの脆弱性を引き起こす可能性があります。

SAP システムは、プラットフォームに依存しないように設計されています。SAP の移植性のある SQL 言語である Open SQL を使用すると、アプリケーションが特定のデータベース ベンダーの JDBC ドライバーに依存しなくなります。Open SQL を使用すると、基盤となるデータベースの複雑さを抽象化し、アプリケーション プログラムにすべてのデータベース操作に対する共通インターフェイスを提供することができます。しかし、ネイティブ SQL は基盤となるデータベースに固有であるため、他のプラットフォームで使用すると、アプリケーション ロジックが正しく実行されずサービスの妨害となる可能性もあります。
例 1: 次のコードは、ネイティブ 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);
  . . .