リソース リークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始することが可能です。

例 1: 次のコードはデータベース クエリを実行しますが、ステートメントも接続リソースも解放しません。

DATA: result        TYPE demo_update,
      request       TYPE REF TO IF_HTTP_REQUEST,
      obj           TYPE REF TO CL_SQL_CONNECTION.           

TRY.
...
    obj = cl_sql_connection=>get_connection( `R/3*my_conn`).
    FINAL(sql) = NEW cl_sql_prepared_statement(
      statement = `INSERT INTO demo_update VALUES( ?, ?, ?, ?, ?, ? )`).

  CATCH cx_sql_exception INTO FINAL(exc).
    ...
ENDTRY.

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始できる可能性があります。

例 1: 次のコードはデータベース クエリを実行しますが、ステートメントまたは接続リソースを解放しません。

- void insertUser:(NSString *)name {
    ...
    sqlite3_stmt *insertStatement = nil;
    NSString *insertSQL = [NSString stringWithFormat:@INSERT INTO users (name, age) VALUES (?, ?)];
    const char *insert_stmt = [insertSQL UTF8String];
    ...
    if ((result = sqlite3_prepare_v2(database, insert_stmt,-1, &insertStatement, NULL)) != SQLITE_OK) {
        MyLog(@"%s: sqlite3_prepare error: %s (%d)", __FUNCTION__, sqlite3_errmsg(database), result);
        return;
    }
    if ((result = sqlite3_step(insertStatement)) != SQLITE_DONE) {
        MyLog(@"%s: step error: %s (%d)", __FUNCTION__, sqlite3_errmsg(database), result);
        return;
    } 
    ...
}

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 通常の条件下では、次のコードはデータベース クエリを実行し、データベースが出力する結果を処理し、割り当てられたステートメント オブジェクトを閉じます。しかし、SQL の実行中または結果処理中に例外が発生すると、ステートメント オブジェクトは閉じません。これが頻繁に発生する場合、データベースは利用できるカーソルが不足し、SQL クエリをそれ以上実行できなくなります。

  Statement stmt = conn.createStatement();
  ResultSet rs = stmt.executeQuery(CXN_SQL);
  harvestResults(rs);
  stmt.close();

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始できる可能性があります。

例 1: 次のコードはデータベース クエリを実行しますが、ステートメントも接続リソースも解放しません。

func insertUser(name:String, age:int) {
    let dbPath = URL(fileURLWithPath: Bundle.main.resourcePath ?? "").appendingPathComponent("test.sqlite").absoluteString
    
    var db: OpaquePointer?
    var stmt: OpaquePointer?

    if sqlite3_open(dbPath, &db) != SQLITE_OK {
        print("Error opening articles database.")
        return
    }
    
    let queryString = "INSERT INTO users (name, age) VALUES (?,?)"
    
    if sqlite3_prepare(db, queryString, -1, &stmt, nil) != SQLITE_OK{
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("error preparing insert: \(errmsg)")
        return
    }

    if sqlite3_bind_text(stmt, 1, name, -1, nil) != SQLITE_OK{
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("failure binding name: \(errmsg)")
        return
    }
    
    if sqlite3_bind_int(stmt, 2, age) != SQLITE_OK{
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("failure binding name: \(errmsg)")
        return
    }

    if sqlite3_step(stmt) != SQLITE_DONE {
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("failure inserting user: \(errmsg)")
        return
    }
}

プログラムはシステムリソースの解放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 次のメソッドは、開いたファイル ハンドルを閉じていません。FileInputStream の finalize() メソッドは最終的に close() をコールしますが、finalize() メソッドが呼び出されるまでにどれくらいの時間がかかるかは保証されません。つまり、使用中の環境では JVM ですべてのファイル ハンドルを使い切ってしまう場合もあります。

private void processFile(String fName) throws FileNotFoundException, IOException {
  FileInputStream fis = new FileInputStream(fName);
  int sz;
  byte[] byteArray = new byte[BLOCK_SIZE];
  while ((sz = fis.read(byteArray)) != -1) {
    processBytes(byteArray, sz);
  }
}

プログラムはシステムリソースの解放に失敗する可能性があります。


リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 次のメソッドは、読み取り先のストリームを閉じていません。

...
CFIndex numBytes;
do {
    UInt8 buf[bufferSize];
    numBytes = CFReadStreamRead(readStream, buf, sizeof(buf));
    if( numBytes > 0 ) {
        handleBytes(buf, numBytes);
    } else if( numBytes < 0 ) {
        CFStreamError error = CFReadStreamGetError(readStream);
        reportError(error);
    }
} while( numBytes > 0 );
...

プログラムはシステム リソースの解放に失敗する可能性があります。

リソース リークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始できる可能性があります。

例 1: 次のメソッドは、開いたファイル ハンドルを閉じていません。

def readFile(filename: String): Unit = {
    val data = Source.fromFile(fileName).getLines.mkString
    // Use the data
}

プログラムはシステムリソースの解放に失敗する可能性があります。


リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service 攻撃を開始できる可能性があります。

例 1: 次のメソッドは、読み取り元のストリームを閉じません。

...
        func leak(reading input: InputStream) {
            input.open()
            let bufferSize = 1024
            let buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: bufferSize)
            while input.hasBytesAvailable {
                let read = input.read(buffer, maxLength: bufferSize)
            }
            buffer.deallocate(capacity: bufferSize)
        }
...

プログラムはシステムリソースの解放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service を開始する可能性があります。

例 1: 次の関数は、エラーが発生した場合に割り当てる条件変数を破壊しています。プロセスが長く続く場合は、プロセスでファイル ハンドルが不足する可能性があります。

int helper(char* fName)
{
   int status;
   ...
   pthread_cond_init (&count_threshold_cv, NULL);
   pthread_mutex_init(&count_mutex, NULL);

   status = perform_operation();
   if (status) {
      printf("%s", "cannot perform operation");
      return OPERATION_FAIL;
   }

   pthread_mutex_destroy(&count_mutex);
   pthread_cond_destroy(&count_threshold_cv);

   return OPERATION_SUCCESS;
}

プログラムはロックの解除に失敗する可能性があります。

リソース リークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させるかデッドロックを起こすことにより、Denial of Service 攻撃を開始する可能性があります。

例 1: 以下のプログラムは、エラーが発生すると、ファイルに対するレコード ロックを解除しません。

  CALL "CBL_GET_RECORD_LOCK"
      USING file-handle
            record-offset
            record-length
            reserved
  END-CALL

  IF return-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      PERFORM write-data
      IF ws-status-code NOT = 0
          DISPLAY "Error!"
          GOBACK
      ELSE
           DISPLAY "Success!"
      END-IF
  END-IF

  CALL "CBL_FREE_RECORD_LOCK"
      USING file-handle
            record-offset
            record-length
            reserved
  END-CALL

  GOBACK
  .

プログラムはシステムリソースの解放に失敗する可能性があります。

リソースリークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。しかし攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、Denial of Service を開始する可能性があります。

例 1: 次のコードは、performOperationInCriticalSection() の前にロックを確立しますが、このメソッドで例外が発生する場合にはロックを解放しません。

ReentrantLock  myLock = new ReentrantLock ();

myLock.lock();
performOperationInCriticalSection();
myLock.unlock();

リソース リークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、サービス拒否攻撃を開始する可能性があります。

例 1: 次のコードは、performOperationInCriticalSection() の前にロックを確立しますが、決してそのロックを解放しません。

os_unfair_lock lock1 = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_lock(&lock1);
performOperationInCriticalSection();

リソース リークには、少なくとも 2 つの一般的原因があります。

- エラー条件などの例外的状況。

- プログラムのどの部分がリソースを解放するかに関する混乱。

開放されていないリソースの問題点の大半は、一般にソフトウェアの信頼性の問題をもたらします。ただし、攻撃者による意図的なリソース リークが可能な場合、攻撃者はリソース プールを枯渇させることにより、サービス拒否攻撃を開始する可能性があります。

例 1: 次のコードは、performOperationInCriticalSection() の前にロックを確立しますが、決してそのロックを解放しません。

let lock1 = OSAllocatedUnfairLock()
lock1.lock()
performOperationInCriticalSection();

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

例 1: プログラマがリフレクション技術を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の例は、リフレクションを使用しないコマンド ディスパッチャです。

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    if (ctl == "Add) {
      ao = new AddCommand();
    } else if (ctl == "Modify") {
      ao = new ModifyCommand();
    } else {
      throw new UnknownActionError();
    }
    ao.doAction(params);

プログラマはこのコードを以下のようにリフレクションを使用するためにリファクタリングすることがあります。

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
    ao = new cmdClass();
    ao.doAction(params);

リファクタリングの実行によって数々の利点が得られるように最初は思われます。コードラインが少なく、if/else ブロックは完全に削除され、コマンドディスパッチャを修正しなくとも新しいコマンドタイプを追加することができるからです。

しかし、リファクタリングによって攻撃者は Worker インターフェイスを実装する任意のオブジェクトのインスタンスを作成することができます。コマンドディスパッチャが依然として Access Control の原因である場合、プログラマは Worker インターフェイスを実装する新規クラスを作成するたびに、ディスパッチャの Access Control コードを忘れずに修正する必要があります。Access Control コードの修正を怠った場合、一部の Worker クラスに対して一切の Access Control が適用されなくなります。

この Access Control の問題を解決する 1 つの方法は、Worker オブジェクトに Access Control のチェックを実行させることです。リファクタリングされたコードの例を次に示します。

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
    ao = new cmdClass();
    ao.checkAccessControl(params);
    ao.doAction(params);

これは改良点ではありますが、Access Control への分散アプローチを推奨することになるため、プログラマが Access Control の失敗を犯しやすくなります。

攻撃者が値を指定し、アプリケーションがそれを使用してどのクラスをインスタンス化するかや、どのメソッドを呼び出すかを決定できてしまうと、攻撃者はアプリケーションを介して予期せぬ制御フロー パスを作成できてしまう可能性があります。これにより、攻撃者が認証チェックやアクセス制御チェックをすり抜けたり、アプリケーションが予期しない方法で動作したりする可能性があります。

例 1: 次のアクション メソッドは、外部 Web サービスへの非同期要求を開始し、continuationMethod プロパティを設定します。これは、応答を受信したときに呼び出されるメソッドの名前を決定します。

public Object startRequest() {
    Continuation con = new Continuation(40);

    Map<String,String> params = ApexPages.currentPage().getParameters();

    if (params.containsKey('contMethod')) {
        con.continuationMethod = params.get('contMethod');
    } else {
        con.continuationMethod = 'processResponse';
    }

    HttpRequest req = new HttpRequest();
    req.setMethod('GET');
    req.setEndpoint(LONG_RUNNING_SERVICE_URL);
    this.requestLabel = con.addHttpRequest(req);
    return con;
}

この実装により、continuationMethod プロパティをランタイム リクエスト パラメーターで設定できるようになり、攻撃者が、名前と一致する関数を呼び出すことが可能になります。

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。

このような状況が発生した場合、攻撃者がアプリケーション パスやライブラリ パスが示す場所にファイルをアップロードすることが可能になると、致命的な結果を招きます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例 1: プログラマがリフレクション API を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の JNI コマンド ディスパッチャの例では、リフレクションを使用して、CGI リクエストから読み込んだ値によって認識された Java メソッドを実行しています。この実装により、攻撃者は clazz で定義された任意の関数をコールできるようになります。

char* ctl = getenv("ctl");
...
jmethodID mid = GetMethodID(clazz, ctl, sig);
status = CallIntMethod(env, clazz, mid, JAVA_ARGS);
...

攻撃者が値を指定し、アプリケーションがそれを使用してどのメソッドを呼び出すかや、どのフィールド値を取得するかを決定できてしまうと、攻撃者はアプリケーションを介して、アプリケーション開発者が意図していなかった制御フロー パスを作成できてしまう可能性があります。この攻撃により、攻撃者が認証チェックやアクセス制御チェックをすり抜けたり、アプリケーションが予期しない方法で動作したりする可能性があります。

例 1: この例では、アプリケーションはコマンドライン引数から、呼び出される関数の名前を取得します。

...
    func beforeExampleCallback(scope *Scope){
        input := os.Args[1]
        if input{
            scope.CallMethod(input)
        }
    }
...
    

例 2: 前の例と同様に、アプリケーションは reflect パッケージを使用して、コマンドライン引数から、呼び出される関数の名前を取得します。

...
    input := os.Args[1]
	var worker WokerType
	reflect.ValueOf(&worker).MethodByName(input).Call([]reflect.Value{})
...

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例 1: プログラマがリフレクション API を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の例は、リフレクションを使用しないコマンド ディスパッチャです。

String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
  ao = new AddCommand();
} else if (ctl.equals("Modify")) {
  ao = new ModifyCommand();
} else {
  throw new UnknownActionError();
}
ao.doAction(request);

プログラマはこのコードを以下のようにリフレクションを使用するためにリファクタリングすることがあります。

    String ctl = request.getParameter("ctl");
    Class cmdClass = Class.forName(ctl + "Command");
    Worker ao = (Worker) cmdClass.newInstance();
    ao.doAction(request);

リファクタリングの実行によって数々の利点が得られるように最初は思われます。コードラインが少なく、if/else ブロックは完全に削除され、コマンドディスパッチャを修正しなくとも新しいコマンドタイプを追加することができるからです。

しかし、リファクタリングによって攻撃者は Worker インターフェイスを実装する任意のオブジェクトのインスタンスを作成することができます。コマンドディスパッチャが依然として Access Control の原因である場合、プログラマは Worker インターフェイスを実装する新規クラスを作成するたびに、ディスパッチャの Access Control コードを忘れずに修正する必要があります。Access Control コードの修正を怠った場合、一部の Worker クラスに対して一切の Access Control が適用されなくなります。

この Access Control の問題を解決する 1 つの方法は、Worker オブジェクトに Access Control のチェックを実行させることです。リファクタリングされたコードの例を次に示します。

String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);

これは改良点ではありますが、Access Control への分散アプローチを推奨することになるため、プログラマが Access Control の失敗を犯しやすくなります。

また、このコードは、コマンド ディスパッチャをビルドするためにリフレクションを使用する別のセキュリティ問題を浮き彫りにします。攻撃者は任意の種類のオブジェクトにデフォルトコンストラクタを呼び出すことができます。実際に、攻撃者は Worker インターフェイスを実装するオブジェクトにすら制約を受けず、システム内の任意のオブジェクトのデフォルト コンストラクタを呼び出すことができます。オブジェクトが Worker インターフェイスを実装しない場合、ao への割り当て前に ClassCastException が発生しますが、コンストラクタが攻撃者に有利に働く操作を実行すると、すでに被害を被ったことになります。このシナリオは、簡単なアプリケーションの場合被害は比較的少なくて済みますが、複雑度が飛躍的に増す大規模アプリケーションの場合では攻撃者は攻撃に利用できるコンストラクタを見つけられると考えるのが妥当です。

直接呼び出し元のクラスローダーチェックを使用してタスクを実行する一部のJava APIが、リフレクションコールで返された信頼のないオブジェクトに対して呼び出された場合には、アクセスチェックがコード実行チェーンのセキュリティにより有効に働く場合があります。これらのJava APIは、実行チェーン内のすべての呼び出し元が必要なセキュリティ権限を持っていることを確認するSecurityManagerチェックをバイパスします。これらのAPIは、セキュリティアクセスチェックをバイパスして、リモートの攻撃に対するシステム脆弱性を残す可能性があるため、リフレクションで返される信頼のないオブジェクトには呼び出さないように注意する必要があります。Java APIの詳細については、『The Secure Coding Guidelines for the Java Programming Language』の「Guideline 9」を参照してください。

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。

例 1: プログラマがセレクター API を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の Objective-C コマンドディスパッチャの例では、リフレクションを使用して、カスタム URL スキームリクエストから読み込んだ値によって認識される任意のメソッドを実行しています。この実装により、攻撃者は UIApplicationDelegate クラスで定義されたメソッド シグネチャに一致する任意の関数をコールできるようになります。

...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
  sourceApplication:(NSString *)sourceApplication annotation:(id)annotation  {

    NSString *query = [url query];
    NSString *pathExt = [url pathExtension];
    [self performSelector:NSSelectorFromString(pathExt) withObject:query];
...

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例 1: プログラマがリフレクション API を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の例は、リフレクションを使用しないコマンド ディスパッチャです。

$ctl = $_GET["ctl"];
$ao = null;
if (ctl->equals("Add")) {
  $ao = new AddCommand();
} else if ($ctl.equals("Modify")) {
  $ao = new ModifyCommand();
} else {
  throw new UnknownActionError();
}
$ao->doAction(request);

プログラマはこのコードを以下のようにリフレクションを使用するためにリファクタリングすることがあります。

    $ctl = $_GET["ctl"];
    $args = $_GET["args"];
    $cmdClass = new ReflectionClass(ctl . "Command");
    $ao = $cmdClass->newInstance($args);
    $ao->doAction(request);

リファクタリングの実行によって数々の利点が得られるように最初は思われます。コードラインが少なく、if/else ブロックは完全に削除され、コマンドディスパッチャを修正しなくとも新しいコマンドタイプを追加することができるからです。

しかし、リファクタリングによって攻撃者は Worker インターフェイスを実装する任意のオブジェクトのインスタンスを作成することができます。コマンドディスパッチャが依然として Access Control の原因である場合、プログラマは Worker インターフェイスを実装する新規クラスを作成するたびに、ディスパッチャの Access Control コードを忘れずに修正する必要があります。Access Control コードの修正を怠った場合、一部の Worker クラスに対して一切の Access Control が適用されなくなります。

この Access Control の問題を解決する 1 つの方法は、Worker オブジェクトに Access Control のチェックを実行させることです。リファクタリングされたコードの例を次に示します。

	$ctl = $_GET["ctl"];
    $args = $_GET["args"];
    $cmdClass = new ReflectionClass(ctl . "Command");
    $ao = $cmdClass->newInstance($args);
	$ao->checkAccessControl(request);
	ao->doAction(request);

これは改良点ではありますが、Access Control への分散アプローチを推奨することになるため、プログラマが Access Control の失敗を犯しやすくなります。

また、このコードは、コマンド ディスパッチャをビルドするためにリフレクションを使用する別のセキュリティ問題を浮き彫りにします。攻撃者は任意の種類のオブジェクトにデフォルトコンストラクタを呼び出すことができます。実際に、攻撃者は Worker インターフェイスを実装するオブジェクトにすら制約を受けず、システム内の任意のオブジェクトのデフォルト コンストラクタを呼び出すことができます。オブジェクトが Worker インターフェイスを実装しない場合、$ao への割り当て前に ClassCastException が発生しますが、コンストラクタが攻撃者に有利に働く操作を実行すると、すでに被害を被ったことになります。このシナリオは、簡単なアプリケーションの場合被害は比較的少なくて済みますが、複雑度が飛躍的に増す大規模アプリケーションの場合では攻撃者は攻撃に利用できるコンストラクタを見つけられると考えるのが妥当です。

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックを回避したり、本来意図されていない行動をアプリケーションにさせたりすることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのロード パス上に現れる場所にアップロードできたり、新しいエントリをアプリケーションのロード パス上に追加できたりしたら、最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例 1: プログラマがリフレクションを使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の例は、リフレクションを使用しないコマンド ディスパッチャです。

ctl = req['ctl']
if ctl=='add'
  addCommand(req)
elsif ctl=='modify'
  modifyCommand(req)
else
  raise UnknownCommandError.new
end

プログラマはこのコードを以下のようにリフレクションを使用するためにリファクタリングすることがあります。

ctl = req['ctl']
ctl << "Command"
send(ctl)

リファクタリングの実行によって数々の利点が得られるように最初は思われます。コードラインが少なく、if/else ブロックは完全に削除され、コマンドディスパッチャを修正しなくとも新しいコマンドタイプを追加することができるからです。

しかし、リファクタリングによって攻撃者は「Command」という単語で終わる任意のメソッドを実行できます。コマンド ディスパッチャが依然として Access Control を担う場合、プログラマは「Command」で終わる新規メソッドを作成するたびに、ディスパッチャの Access Control コードを忘れずに修正する必要があります。その場合でも、似た名前を持つ複数のメソッドがある場合の一般的な対処方法は、これらを define_method() を使用して動的に作成するか、missing_method() の上書きによってコールすることです。こうした状況とそこでアクセス制御コードがどう使用されるかを監査し、追跡するのは非常に困難です。また、他のどのライブラリ コードがロードされたかにも依存することを考えると、この作業をこの方法で適切に行うことはほぼ不可能です。

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例 1: プログラマがリフレクション API を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の例は、リフレクションを使用するコマンド ディスパッチャです。

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(ctl + "Command")
    Worker ao = (Worker) cmdClass.newInstance()
    ao.doAction(request)
    ...
}

リファクタリングの実行によって数々の利点が得られるように最初は思われます。コード ラインが少なく、if/else ブロックは完全に削除され、コマンド ディスパッチャを修正しなくとも新しいコマンド タイプを追加することができるからです。

しかし、リファクタリングによって攻撃者は Worker インターフェイスを実装する任意のオブジェクトのインスタンスを作成することができます。コマンド ディスパッチャが依然として Access Control の原因である場合、プログラマは Worker インターフェイスを実装する新規クラスを作成するたびに、ディスパッチャの Access Control コードを忘れずに修正する必要があります。Access Control コードの修正を怠った場合、一部の Worker クラスに対して一切の Access Control が適用されなくなります。

この Access Control の問題を解決する 1 つの方法は、Worker オブジェクトに Access Control のチェックを実行させることです。リファクタリングされたコードの例を次に示します。

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(ctl + "Command")
    Worker ao = (Worker) cmdClass.newInstance()
    ao.checkAccessControl(request);
    ao.doAction(request)
    ...
}

これは改良点ではありますが、Access Control への分散アプローチを推奨することになるため、プログラマが Access Control の失敗を犯しやすくなります。

また、このコードは、コマンド ディスパッチャをビルドするためにリフレクションを使用する別のセキュリティ問題を浮き彫りにします。攻撃者は任意の種類のオブジェクトにデフォルトコンストラクタを呼び出すことができます。実際に、攻撃者は Worker インターフェイスを実装するオブジェクトにすら制約を受けず、システム内の任意のオブジェクトのデフォルト コンストラクタを呼び出すことができます。オブジェクトが Worker インターフェイスを実装しない場合、ao への割り当て前に ClassCastException が発生しますが、コンストラクタが攻撃者に有利に働く操作を実行すると、すでに被害を被ったことになります。このシナリオは、簡単なアプリケーションの場合被害は比較的少なくて済みますが、複雑度が飛躍的に増す大規模アプリケーションの場合では攻撃者は攻撃に利用できるコンストラクタを見つけられると考えるのが妥当です。

直接呼び出し元のクラスローダーチェックを使用してタスクを実行する一部のJava APIが、リフレクションコールで返された信頼のないオブジェクトに対して呼び出された場合には、アクセスチェックがコード実行チェーンのセキュリティにより有効に働く場合があります。これらのJava APIは、実行チェーン内のすべての呼び出し元が必要なセキュリティ権限を持っていることを確認するSecurityManagerチェックをバイパスします。これらのAPIは、セキュリティアクセスチェックをバイパスして、リモートの攻撃に対するシステム脆弱性を残す可能性があるため、リフレクションで返される信頼のないオブジェクトには呼び出さないように注意する必要があります。Java APIの詳細については、『The Secure Coding Guidelines for the Java Programming Language』の「Guideline 9」を参照してください。

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。

例 1: プログラマがセレクター API を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の Swift コマンド ディスパッチャの例では、リフレクションを使用して、カスタム URL スキーム リクエストから読み込んだ値によって認識される任意のメソッドを実行しています。この実装により、攻撃者は UIApplicationDelegate クラスで定義されたメソッド シグネチャに一致する任意の関数をコールできるようになります。

func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let query = url.query
    let pathExt = url.pathExtension
    let selector = NSSelectorFromString(pathExt!)
    performSelector(selector, withObject:query)
    ...
}

インスタンス化すべきクラスや、呼び出すべきメソッドを決定するためにアプリケーションが使用する値を攻撃者が指定できる場合、アプリケーション開発者の想定外の制御フローパスを攻撃者が作成できる可能性があります。この攻撃手段では、攻撃者は Authentication や Access Control チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

例 1: プログラマが CallByName を使用する一般的な理由は、独自のコマンド ディスパッチャを実装するためです。次の例は、CallByName 関数を使用しないコマンド ディスパッチャです。

...
Dim ctl As String
Dim ao As new Worker
ctl = Request.Form("ctl")
If String.Compare(ctl,"Add") = 0 Then
	ao.DoAddCommand Request
Else If String.Compare(ctl,"Modify") = 0 Then
	ao.DoModifyCommand Request
Else
	App.EventLog "No Action Found", 4
End If
...

プログラマはこのコードを以下のようにリフレクションを使用するためにリファクタリングすることがあります。

...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
CallByName ao, ctl, vbMethod, Request
...

リファクタリングの実行によって数々の利点が得られるように最初は思われます。コードラインが少なく、if/else ブロックは完全に削除され、コマンドディスパッチャを修正しなくとも新しいコマンドタイプを追加することができるからです。

しかし、リファクタリングによって攻撃者は Worker オブジェクトによって実装された任意のメソッドを呼び出すことができます。コマンドディスパッチャが依然として Access Control の原因である場合、プログラマは Worker クラス内に新規メソッドを作成するたびに、ディスパッチャの Access Control コードを忘れずに修正する必要があります。Access Control コードの修正を怠った場合、一部の Worker メソッドに対して一切の Access Control が適用されなくなります。

この Access Control の問題を解決する 1 つの方法は、Worker オブジェクトに Access Control のチェックを実行させることです。リファクタリングされたコードの例を次に示します。

...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
If ao.checkAccessControl(ctl,Request) = True Then
	CallByName ao, "Do" & ctl & "Command", vbMethod, Request
End If
...

これは改良点ではありますが、Access Control への分散アプローチを推奨することになるため、プログラマが Access Control の失敗を犯しやすくなります。