最近の多くの Web スクリプト言語では、1 つのカプセル化ファイル内にソースファイルをインクルードする機能を使用することによって、コードの再利用やモジュール化が可能です。多くの場合、この機能は標準的なルックアンドフィールをアプリケーションに適用したり (テンプレート化)、コンパイル済みコードを用いることなく機能を共有したり、より管理しやすい小さなファイルにコードを分割したりするために使用されます。インクルードファイルは親ファイルの一部として解釈され、同様の方法で実行されます。File Inclusion の脆弱性は、インクルードファイルのパスが未検証のユーザー入力によって制御された場合に発生します。

例 1: 次のコードでは、ユーザー指定のテンプレート名を取得し、レンダリングされる HTML ページに追加しています。

...
ClientScript.RegisterClientScriptInclude("RequestParameterScript", HttpContext.Current.Request.Params["includedURL"]);
...

Example 1 では、攻撃者は悪意ある値を includedURL に指定することによって、動的な include ステートメントを完全に制御できます。その結果、プログラムは外部サイトからのファイルをインクルードしてしまいます。

攻撃者が有効なファイルを動的な include ステートメントに指定した場合、.NET はそのファイルの内容をユーザーに送信される HTML ファイルに挿入します。web.config などの平文のファイルである場合には、そのファイルは HTML 出力の一部としてレンダリングされる可能性があります。より深刻なケースでは、攻撃者が自身の制御下にあるリモート サイトへのパスを指定できる場合、動的な include ステートメントでは攻撃者が指定した任意の悪意あるコードが実行されることとなります。

最近の多くの Web スクリプト言語では、1 つのカプセル化ファイル内にソースファイルをインクルードする機能を使用することによって、コードの再利用やモジュール化が可能です。多くの場合、この機能は標準的なルックアンドフィールをアプリケーションに適用したり (テンプレート化)、コンパイル済みコードを用いることなく機能を共有したり、より管理しやすい小さなファイルにコードを分割したりするために使用されます。インクルードファイルは親ファイルの一部として解釈され、同様の方法で実行されます。File Inclusion の脆弱性は、インクルードファイルのパスが未検証のユーザー入力によって制御された場合に発生します。

File Inclusion の脆弱性は、最も数が多く、被害の深刻な PHP アプリケーションの脆弱性の 1 つです。PHP 4.2.0 より前のバージョンでは、PHP は register_globals オプションがデフォルトで有効に設定された状態で頒布されていたため、攻撃者は簡単に内部サーバー変数を上書きできました。register_globals オプションを無効にすることによってプログラムが File Inclusion の脆弱性にさらされる危険性は制限できますが、この問題は最近の PHP アプリケーションでも発生しています。

例 1: 次のコードは、テンプレートで $server_root と定義されているアプリケーションの下にファイルをインクルードしています。

...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...

register_globals が on に設定されている場合、攻撃者はリクエストパラメーターとして $server_root を指定することによって $server_root の値を上書きできるため、動的な include ステートメントを部分的に制御できるようになります。

例 2: 次のコードでは、ユーザー指定のテンプレート名を取得し、レンダリングされる PHP ページにそのテンプレート名を追加しています。

...
<?php include($_GET['headername']); ?$gt;
...

Example 2 では、攻撃者は悪意ある値を headername に指定することによって、動的な include ステートメントを完全に制御できます。その結果、プログラムは外部サイトからのファイルをインクルードしてしまいます。

攻撃者が有効なファイルを動的な include ステートメントに指定した場合、そのファイルの内容は PHP インタプリタに渡されます。/etc/shadow などの平文のファイルである場合には、そのファイルは HTML 出力の一部としてレンダリングされる可能性があります。より深刻なケースでは、攻撃者が自身の制御下にあるリモート サイトへのパスを指定できる場合、動的な include ステートメントでは攻撃者が指定した任意の悪意あるコードが実行されることとなります。

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになり、その結果、リソースが使い果たされる条件が作成されます。

例 1: 次のコードでは、現在の処理プロセスがスリープ状態になる期間をユーザーが指定できるようにしています。大きい数値を指定することで、攻撃者は無期限に処理プロセスを拘束する可能性があります。

...
CALL FUNCTION 'ENQUE_SLEEP'
  EXPORTING
    SECONDS = usrInput.
...

クライアントの IP アドレスに基づいて RateLimitPartitions を作成すると、アプリケーションは、IP ソース アドレス スプーフィングを使用する Denial of Service 攻撃に対して脆弱になります。
例 1: 次の例では、GetTokenBucketLimiter() メソッドが、リモート IP アドレス (RemoteIpAddress) を、RateLimitPartition の作成時にパーティション キーとして使用します。

...
builder.Services.AddRateLimiter(limiterOptions => {
    limiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, IPAddress>(context => {
        IPAddress? ip = context.Connection.RemoteIpAddress;
        return RateLimitPartition.GetTokenBucketLimiter(ip!, _ =>
            new TokenBucketRateLimiterOptions
            {
                TokenLimit = 7
            });
    });
});
...

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになります。

例 1: 次のコードは、現在のプロセスがスリープ状態になる時間をユーザーが指定することを許しています。大きい数値を指定することで、攻撃者は無期限にプロセスを拘束することができます。

  unsigned int usrSleepTime = uatoi(usrInput);
  sleep(usrSleepTime);

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになります。

例 1: 次のコードは、スレッドがスリープ状態になる時間をユーザーが指定することを許しています。攻撃者は大きな数を指定することで、スレッドを無期限に拘束できます。数回のリクエストで、攻撃者はアプリケーションのスレッド プールを使い果たすことができます。

Sleep(url.duration);

攻撃者は、アプリケーションをリクエストでフラッディングして、正当なユーザーへのサービスを拒否する可能性がありますが、フラッディング攻撃が拡散するのはネットワーク層です。さらに問題なのは、攻撃者が少量のリクエストを使用してアプリケーションを過負荷にするバグです。このようなバグにより、リクエストが消費するシステム リソースの量や、それらを使用する期間を攻撃者が指定できます。

例 1: 次のコードでは、ユーザーが Future 関数の実行時間を指定できます。大きな数値を指定すると、攻撃者が Future 関数を無期限に拘束する可能性があります。

  final duration = Platform.environment['DURATION'];
  Future.delayed(Duration(seconds: int.parse(duration!)), () => ...);

攻撃者は、アプリケーションをリクエストでフラッディングして、正当なユーザーへのサービスを拒否する可能性がありますが、フラッディング攻撃が拡散するのはネットワーク層です。さらに問題なのは、攻撃者が少量のリクエストを使用してアプリケーションを過負荷にするバグです。このようなバグにより、リクエストが消費するシステム リソースの量や、それらを使用する期間を攻撃者が指定できます。

例 1: 信頼されていないデータでのサービス タイムアウトを設定すると、攻撃者が大きな値を設定した場合にサービスが応答しなくなります。

func test(r *http.Request) {
  ...
  i, _ := strconv.Atoi(r.FormValue("TIME"))
  runtime.KeepAlive(i)
  ...
  }

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになります。

例 1: 次のコードは、使用されるファイル システムのサイズをユーザーが指定することを許しています。大きい数値を指定することで、攻撃者はファイル システムのリソースを枯渇させることができます。

  var fsync = requestFileSystemSync(0, userInput);

例 2: 次のコードは、ファイルに書き込みを行っています。このファイルは、ユーザー エージェントによって閉じられたと判断されるまで継続的に書き込みと再書き込みが実行されることがあるため、ファイルの内容を分析するのに必要なディスク クオータ、IO 帯域幅、およびプロセスが影響を受ける場合があります。

function oninit(fs) {
  fs.root.getFile('applog.txt', {create: false}, function(fileEntry) {
    fileEntry.createWriter(function(fileWriter) {
      fileWriter.seek(fileWriter.length);
      var bb = new BlobBuilder();
      bb.append('Appending to a file');
      fileWriter.write(bb.getBlob('text/plain'));
    }, errorHandler);
  }, errorHandler);
}

window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになります。

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになります。

例 1: 次のコードは、システムが後続の処理をどれだけの時間遅延させるのかをユーザーが指定することを許しています。攻撃者は大きな数を指定することで、システムを無期限に拘束できます。

procedure go_sleep (
usrSleepTime in NUMBER)
is
  dbms_lock.sleep(usrSleepTime);

攻撃者は、アプリケーションをリクエストでフラッディングして、正当なユーザーへのサービスを拒否する可能性がありますが、ほとんどのフラッディング攻撃が拡散するのはネットワーク層です。さらに問題なのは、攻撃者が少量のリクエストを使用してアプリケーションを過負荷にする不具合です。このような不具合により、リクエストが消費するシステム リソースの量や、それらを使用する期間を攻撃者が指定できます。

例 1: 次のコードでは、ユーザーが connect 関数の接続タイムアウトの期間を指定できます。大きな数値を指定すると、攻撃者が connect 関数を無期限に拘束する可能性があります。

...
insecure_config_ssl_connection_timeout = {
  'user': username,
  'password': retrievedPassword,
  'host': databaseHost,
  'port': "3306",
  'connection_timeout': connection_timeout
}

mysql.connector.connect(**insecure_config_ssl_connection_timeout)
...

攻撃者は大量のリクエストをアプリケーションに送りつけることで、正規ユーザーへのサービスを拒否させる可能性がありますが、フラッド攻撃は、ネットワークレイヤで除去できる場合があります。さらに解決が難しいのは、攻撃者が数回のリクエストでアプリケーションに過剰な負荷をかけることを可能とするバグです。このようなバグが利用されると、攻撃者はリクエストによって消費するシステムリソースの数量や、システムリソースが使用される期間を指定できるようになります。

例 1: 次のコードは、スレッドがスリープ状態になる時間をユーザーが指定することを許しています。攻撃者は大きな数を指定することで、スレッドを無期限に拘束できます。数回のリクエストで、攻撃者はアプリケーションのスレッド プールを使い果たすことができます。

  Kernel.sleep(user_input)

例 2: The following code reads a String from a file.このコードでは、readline() メソッドが制限を指定せずに使用されているため、無制限の入力が読み取られます。攻撃者はこのコードを利用し、メモリを大量に使用してプロセスをハングアップさせることができます。最終的にメモリをすべて使い果たすことがあります。

  fd = File.new(myFile)
  line = fd.readline

正規表現の評価機能および関連メソッドの実装には、繰り返されるグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、繰り返されるグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。攻撃者はこの不具合を利用して、サービス妨害 (DoS) 攻撃の実行に使用する可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1: 次の正規表現が、確認済みの脆弱なコードで使用された場合、サービス拒否が発生する可能性があります。

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

欠陥のある正規表現に依存している問題のあるコードの例を次に示します。

NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
  //do something
}

大半の正規表現パーサーは、正規表現の評価時に非決定性有限オートマトン (Nondeterministic Finite Automaton: NFA) 構造体を作成します。NFA は、完全一致が見つかるまで、あらゆる一致を試みます。上記の例を踏まえると、攻撃者が "eeeeZ" という一致文字列を指定した場合、正規表現パーサーが一致を特定するまでに実行しなくてはならない内部評価は 16 件あります。攻撃者が 16 個の "e" ("eeeeeeeeeeeeeeeeZ") を一致文字列として指定した場合には、正規表現パーサーは 65536 (2^16) 回の評価を実行する必要があります。攻撃者は、連続する一致文字の数を増やすことによって、容易にコンピューティング リソースを消費できます。この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。 さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。 この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。 すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、ネスト化され繰り返されている正規表現グループの重複を評価・変更した場合にスレッドをハングさせる可能性のある脆弱性が存在します。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

(e+)+
([a-zA-Z]+)*

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。
例 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

正規表現の評価機能および関連メソッドの実装には、自分自身を繰り返すグループ化式を含む正規表現を評価する場合にスレッドをハングさせる可能性のある脆弱性が存在します。さらに、互いに重複する代替の部分式を含む正規表現も悪用される可能性があります。この不具合は、サービス拒否 (DoS) 攻撃の実行に使用される可能性があります。

例 1: 次の正規表現が、確認済みの脆弱なコードで使用された場合、サービス拒否が発生する可能性があります。

(e+)+
([a-zA-Z]+)*
(e|ee)+

欠陥のある正規表現に依存している問題のあるコードの例を次に示します。

let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
  //do something
}

大半の正規表現パーサーは、正規表現の評価時に非決定性有限オートマトン (Nondeterministic Finite Automaton: NFA) 構造体を作成します。NFA は、完全一致が見つかるまで、あらゆる一致を試みます。Example 1 を踏まえると、攻撃者が "eeeeZ" という一致文字列を指定した場合、正規表現パーサーが一致を特定するまでに実行しなくてはならない内部評価は 16 件あります。攻撃者が 16 個の "e" ("eeeeeeeeeeeeeeeeZ") を一致文字列として指定した場合には、正規表現パーサーは 65536 (2^16) 回の評価を実行する必要があります。攻撃者は、連続する一致文字の数を増やすことによって、容易にコンピューティング リソースを消費できます。この脆弱性の影響を受けない既知の正規表現の実装はありません。すべてのプラットフォームと言語がこの攻撃に対して脆弱です。

デフォルトのバッキング文字配列サイズ (16) で初期化された StringBuilder または StringBuffer インスタンスにユーザー制御のデータを追加すると、基礎となる配列をユーザーのデータに合わせてサイズ変更するときにアプリケーションが大量のヒープ メモリを消費するようになる可能性があります。StringBuilder または StringBuffer インスタンスにデータが追加されると、インスタンスは、バッキング文字配列にデータを保存できる十分な空き領域があるかどうかを判断します。データが適合しない場合、StringBuilder または StringBuffer インスタンスは前の配列サイズの 2 倍以上の容量を持つ新しい配列を作成します。古い配列はガベージ コレクトされるまでヒープ内に残ります。攻撃者はこの実装の詳細を利用して、Denial of Service (DoS) 攻撃を実行する可能性があります。

例 1: デフォルトのコンストラクタで初期化された StringBuilder インスタンスにユーザー制御のデータが追加されます。

    ...
    val sb = StringBuilder()
    val labels = request.getParameterValues("label")
    for (label in labels) {
        sb.appendln(label)
    }
    ...

コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例において、レポートは実行されるコマンドを指定することをユーザーに許してしまう基本的な計算機能を実装しています。

...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
             calculator_code_begin user_ops calculator_code_end INTO code_string,
			 'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...

operation パラメーターが悪意のない値である場合、プログラムは正常に動作します。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、挿入されたコードによってシステム リソースにアクセスする場合や、システム コマンドを実行する場合に、より危険性が高まります。たとえば、攻撃者が "MOVE 'shutdown -h now' を cmd に指定した場合、CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." を operation の値として指定すると、ホスト システムでシャットダウン コマンドが実行されます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var userOps:String = String(params["operation"]);
        result = ExternalInterface.call("eval", userOps);
...

operation パラメーターが "8 + 7 * 2"などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。ActionScript の場合、攻撃者はこの脆弱性を利用してクロスサイト スクリプト攻撃を実行できます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
    public static object CEval(string sCSCode)
    {
        CodeDomProvider icc = CodeDomProvider.CreateProvider("CSharp"); 
        CompilerParameters cparam = new CompilerParameters();
        cparam.ReferencedAssemblies.Add("system.dll");
        cparam.CompilerOptions = "/t:library";
        cparam.GenerateInMemory = true;

        StringBuilder sb_code = new StringBuilder("");
        sb_code.Append("using System;\n");
        sb_code.Append("namespace Fortify_CodeEval{ \n");
        sb_code.Append("public class FortifyCodeEval{ \n");
        sb_code.Append("public object EvalCode(){\n");
        sb_code.Append(sCSCode + "\n");
        sb_code.Append("} \n");
        sb_code.Append("} \n");
        sb_code.Append("}\n");

        CompilerResults cr = icc.CompileAssemblyFromSource(cparam, sb_code.ToString());
        if (cr.Errors.Count > 0)
        {
            logger.WriteLine("ERROR: " + cr.Errors[0].ErrorText);
            return null;
        }

        System.Reflection.Assembly a = cr.CompiledAssembly;
        object o = a.CreateInstance("Fortify_CodeEval.FortifyCodeEval");

        Type t = o.GetType();
        MethodInfo mi = t.GetMethod("EvalCode");

        object s = mi.Invoke(o, null);
        return s;
    }
...

このプログラムは、sCSCode パラメーターが "return 8 + 7 * 2" などの無害な値であれば正しく動作し、その場合、関数 CEval の戻り値は 22 となります。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、.Net では Windows API の呼び出しが可能です。攻撃者が operation の値として " return System.Diagnostics.Process.Start(\"shutdown\", \"/s /t 0\");" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
	userOp = form.operation.value;
	calcResult = eval(userOp);
...

operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、calcResult 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。JavaScript の場合、攻撃者はこの脆弱性を利用してクロスサイト スクリプト攻撃を実行できます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: 次のコードは、UITextField からの入力を使用して、WKWebView 内でコンテンツの背景色を動的に変更します。

...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...

プログラムは、UITextField の入力が "blue" などの無害の値であれば正しく作動し、その場合、webView 内の <body> 要素は青い背景のスタイルになります。一方、攻撃者が悪意があるにもかかわらず有効な入力を使用する場合は、任意の JavaScript コードを実行できる可能性があります。たとえば、JavaScript は cookie など特定タイプの個人情報にアクセスできるので、攻撃者が "white";document.body.innerHTML=document.cookie;"" を UITextField への入力として指定すると、cookie 情報が可視的にそのページに書き込まれます。このような攻撃は、基盤の言語がシステム リソースへのアクセスを提供したりシステム コマンドの実行を可能にしたりする場合にさらに危険になります。そのようなシナリオでは、挿入されたコードが親プロセスの全権限とともに実行されるからです。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
	$userOps = $_GET['operation'];
	$result = eval($userOps);
...

operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、攻撃者が operation の値として " exec('shutdown -h now')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
userOps = request.GET['operation']
result = eval(userOps)
...

operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、攻撃者が operation の値として " os.system('shutdown -h now')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。
例 1: このコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
  user_ops = req['operation']
  result = eval(user_ops)
...

operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、result 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。Ruby では、これは許可されます。また、行をセミコロン (;) で区切ることで複数のコマンドを実行できるため、プログラムを不正使用しなくても、単純な挿入で多くのコマンドを実行することもできるようになります。
攻撃者がパラメーター operation "system(\"nc -l 4444 &\");8+7*2" を送信すると、ポート 4444 が開いてマシン上の接続をリスンしますが、result には値 22 を返します。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: 次のコードは、UITextField からの入力を使用して、WKWebView 内でコンテンツの背景色を動的に変更します。

...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...

プログラムは、UITextField の入力が "blue" などの無害の値であれば正しく作動し、その場合、webView 内の <body> 要素は青い背景のスタイルになります。一方、攻撃者が悪意があるにもかかわらず有効な入力を使用する場合は、任意の JavaScript コードを実行できる可能性があります。たとえば、JavaScript は cookie など特定タイプの個人情報にアクセスできるので、攻撃者が "white";document.body.innerHTML=document.cookie;"" を UITextField への入力として指定すると、cookie 情報が可視的にそのページに書き込まれます。このような攻撃は、基盤の言語がシステム リソースへのアクセスを提供したりシステム コマンドの実行を可能にしたりする場合にさらに危険になります。そのようなシナリオでは、挿入されたコードが親プロセスの全権限とともに実行されるからです。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。ユーザー入力の命令をデータに対して実行する必要があるが、ユーザー入力を解釈するコードを実装する代わりにプログラミング言語の構造体を利用することをプログラマが希望している場合に、この機能が役立ちます。ユーザーが入力する命令は、アクティブなユーザーオブジェクトに関する小規模な計算やユーザーオブジェクトの状態の変更など、害のない操作であることが想定されています。しかし、プログラマが不注意であった場合、攻撃者はプログラマの意図していない操作を指定できる可能性があります。

例 1: 基本となるプログラミング言語の構造体がユーザーによって指定される可能性がある典型的なアプリケーションとして、計算機能が挙げられます。次の ASP コードは、ユーザーが入力した基本的な算術操作を受け入れて計算し結果を返しています。

...
	strUserOp = Request.Form('operation')
	strResult = Eval(strUserOp)
...

プログラムの意図したとおりの動作は、operation パラメーターが"8 + 7 * 2" である例に示されます。strResult 変数は、値 22 を戻します。しかし、ユーザーが有効なそのほかの言語操作を指定する場合、それらの操作は実行されるだけでなく、親プロセスの完全な権限で実行されます。基礎となる言語によってシステムリソースにアクセスできる場合やシステムコマンドの実行が認められている場合、任意のコード実行がもたらす危険性はより高まります。たとえば、攻撃者が operation に " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: このコード挿入の例では、リクエストパラメーターは評価される razor テンプレートにバインドされます。

...
	string name = Request["username"];
	string template = "Hello @Model.Name! Welcome " + name + "!";
	string result = Razor.Parse(template, new { Name = "World" });
...

プログラムは、operation パラメーターが悪意のない値、たとえば "John" (この場合は result 変数に "Hello World!Welcome John!" の値が割り当てられる) などの場合に正しく動作します。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。たとえば、RazorでC#オブジェクトの呼び出しが可能です。攻撃者がnameの値として" @{ System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.EnableRaisingEvents=false; proc.StartInfo.FileName=\"calc\"; proc.Start(); }"を指定した場合、ホストシステムではシステムコマンドが実行されます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。この機能により、プログラマはユーザー入力に基づいた動的な命令の実行が可能です。コード挿入の脆弱性が発生するのは、プログラマが「ユーザーから直接入力された命令は、害のない操作 (アクティブなユーザーオブジェクトについての単純な計算や、ユーザーの状態の変更など) のみを実行する」という誤った想定をした場合です。しかし、適切な検証を行わなかった場合、ユーザーがプログラマの意図とは異なる操作を指定する可能性があります。

例 1: この典型的なコード挿入の例では、アプリケーションは、実行するコマンドの指定をユーザーに許可する基本的な計算機能を実装しています。

...
    userOp = form.operation.value;
    calcResult = eval(userOp);
...

operation パラメーターが「8 + 7 * 2」などの悪意のない値である場合、プログラムは正しく動作します。この場合、calcResult 変数には値 22 が割り当てられます。しかし、攻撃者が有効かつ悪意のある言語操作を指定した場合、指定された操作は親プロセスの完全な権限で実行されます。このような攻撃は、基盤となる言語によってシステムリソースにアクセスできる場合や、システムコマンドの実行が認められている場合に、より危険性が高まります。JavaScript の場合、攻撃者はこの脆弱性を利用してクロスサイト スクリプト攻撃を実行できます。

最近のプログラミング言語では、ソース命令の動的な解釈が可能です。ユーザー入力の命令をデータに対して実行する必要があるが、ユーザー入力を解釈するコードを実装する代わりにプログラミング言語の構造体を利用することをプログラマが希望している場合に、この機能が役立ちます。ユーザーが入力する命令は、アクティブなユーザーオブジェクトに関する小規模な計算やユーザーオブジェクトの状態の変更など、害のない操作であることが想定されています。しかし、プログラマが不注意であった場合、攻撃者はプログラマの意図していない操作を指定できる可能性があります。

例 1: 基本となるプログラミング言語の構造体がユーザーによって指定される可能性がある典型的なアプリケーションとして、計算機能が挙げられます。次の ASP コードは、ユーザーが入力した基本的な算術操作を受け入れて計算し結果を返しています。

...
        strUserOp = Request.Form('operation')
        strResult = Eval(strUserOp)
...

プログラムの意図したとおりの動作は、operation パラメーターが"8 + 7 * 2" である例に示されます。strResult 変数は、値 22 を戻します。しかし、ユーザーが有効なそのほかの言語操作を指定する場合、それらの操作は実行されるだけでなく、親プロセスの完全な権限で実行されます。基礎となる言語によってシステムリソースにアクセスできる場合やシステムコマンドの実行が認められている場合、任意のコード実行がもたらす危険性はより高まります。たとえば、攻撃者が operation に " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" を指定した場合、ホスト システムでは shutdown コマンドが実行されます。

.NET シリアライゼーションでは、オブジェクト グラフはオブジェクト自体と必要なメタデータを含むバイトまたは XML ストリームに変換され、そのストリームからそれらが再構築されます。開発者はカスタム コードを作成して .NET オブジェクトのデシリアライズのプロセスを支援できます。その際には、デシリアライズされたオブジェクトを別のオブジェクトまたはプロキシで置き換えられます。カスタマイズされたデシリアライズ プロセスは、オブジェクトがアプリケーションに返され、目的のタイプにキャストされる前に、オブジェクトの再構築中に実行されます。開発者が目的のタイプを強制するまでに、コードはすでに実行されていることがあります。

例 1: 次の関数は接続から Stream オブジェクトを入力として受け取り、デシリアライズして .NET オブジェクトに戻します。次に文字列オブジェクトのリストにキャストしてから結果を返します。

...
List <string> Deserialize(Stream input)
{
  var bf = new BinaryFormatter();
  var result = (List <string>)bf.Deserialize(input); 
  return result;
}
...

わかりやすくするため、Example 1 は次のように書き換えることができます。

例 2:

...
List <string> Deserialize(Stream input)
{
  var bf = new BinaryFormatter();
  object tmp = bf.Deserialize(input);
  List <string> result = (List <string>)tmp;
  return result;
}
...

Example 2 では、入力ストリームが有効であれば、そのタイプが List <string> であるかどうかに関係なく、デシリアライズ操作は成功します。

カスタムのデシリアライズ ルーチンは、bin フォルダまたは GAC に存在している必要があるシリアライズ可能なクラスで定義され、攻撃者が挿入できないので、これらの攻撃による悪用の可能性はアプリケーション環境で利用可能なクラスに依存します。残念ながら、一般的なサードパーティのクラスまたは .NET のクラスでさえ悪用され、システム リソースを枯渇させたり、悪意あるファイルが展開されたり、任意のコードが実行されたりすることがあります。

オブジェクト グラフを Json フォーマット データに変える Json シリアライゼーション ライブラリは、オブジェクトを Json ストリームから再構築するために必要なメタデータを含む可能性があります。攻撃者が再構築されるオブジェクトのタイプを指定し、アプリケーションでユーザー制御データを含む任意のセッターを実行するように強制できる場合、Json ストリームのデシリアライゼーション時に任意のコードを実行できることがあります。

オブジェクト グラフを YAML フォーマット データに変換する YAML シリアライゼーション ライブラリは、オブジェクトを YAML ストリームから再構築するために必要なメタデータを含む可能性があります。 攻撃者が再構築されるオブジェクトのクラスを指定でき、アプリケーションでユーザー制御データを含む任意のセッターを実行するように強制できる場合、YAML ストリームのデシリアライゼーション時に任意のコードを実行できることがあります。

例: 次の例では、YamlDotNet パーサーを使用して信頼されていない YAML 文字列をデシリアライズします。

    var yamlString = getYAMLFromUser();

    // Setup the input
    var input = new StringReader(yamlString);

    // Load the stream
    var yaml = new YamlStream();
    yaml.Load(input);