内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 次のコードは、スタックトレースを「デバッグ」コンソールまたはログファイルに出力します。

  try {
    ...
  }
  catch(e:Error) {
    trace(e.getStackTrace());
  }

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラーメッセージから、システムがどのような攻撃に対して脆弱か攻撃者が正確に把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、検索パスに、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 次のコードは、例外メッセージをデバッグ ログに書き込みます。

try {
    ...
} catch (Exception e) {
    System.Debug(LoggingLevel.ERROR, e.getMessage());
}

エラー メッセージを基に、攻撃者が攻撃を計画する可能性があります。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。
例 1: 次のコードはデータベース接続文字列を構成し、それを使用してデータベースへの新しい接続を作成して、コンソールに書き込みます。

string cs="database=northwind;server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs);
...
Console.Writeline(cs);

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システムデータやデバッグ情報がローカルのファイル、コンソール、または画面にロギングや印刷を通じて送信される時に発生します。
例 1: 次のコードを実行すると、パス環境変数が標準エラーストリームに出力されます。

  char* path = getenv("PATH");
  ...
  fprintf(stderr, "cannot find exe on path %s\n", path);

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラーメッセージから、システムがどのような攻撃に対して脆弱か攻撃者が正確に把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、検索パスに、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システムデータやデバッグ情報がローカルのファイル、コンソール、または画面にロギングや印刷を通じて送信される時に発生します。
例: 次のコードは、すべてのタスク関連のストレージ領域、ターミナルコントロールテーブル、および指定されたデータエリアのトランザクションダンプを要求しています。

...
EXEC CICS DUMP TRANSACTION
  DUMPCODE('name')
  FROM (data-area)
  LENGTH (data-value)
END-EXEC.
...

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラーメッセージから、システムがどのような攻撃に対して脆弱か攻撃者が正確に把握してしまいます。たとえば、あるデータベースのエラーメッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラーメッセージがシステムに関する間接的な手がかりを示すことがあります。

内部的な情報漏えいは、システムデータやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送られるとき発生します。

例: 以下のコードは、ローカルのファイル システムにあるファイルに書き込まれます。

<cfscript>
    try { 
        obj = CreateObject("person"); 
    } 
    catch(any excpt) { 
        f = FileOpen("c:\log.txt", "write"); 
        FileWriteLine(f, "#excpt.Message#");
        FileClose(f);
    }
</cfscript>

この情報は、ログファイルに書き込まれます。場合によってはメッセージから、システムがどのような攻撃に対して脆弱か攻撃者が正確に把握してしまいます。たとえば、あるデータベースのエラーメッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラーメッセージがシステムに関する間接的な手がかりを示すことがあります。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 次のコードは、例外をローカル ファイルに書き込みます。

  final file = await File('example.txt').create();
  final raf = await file.open(mode: FileMode.write);
  final data = String.fromEnvironment("PASSWORD");
  raf.writeString(data);

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

情報漏洩は、モバイル コンピューティング環境でも懸念事項です。

内部的な情報漏えいは、システムデータやデバッグ情報がローカルのファイル、コンソール、または画面にロギングや印刷を通じて送信される時に発生します。
例 1: 次のコードを実行すると、パス環境変数が標準エラーストリームに出力されます。

  path := os.Getenv("PATH")
  ...
  log.Printf("Cannot find exe on path %s\n", path)

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、検索パスに、オペレーティング システムのタイプ、システムにインストールされているアプリケーション、プログラムの設定に対する管理者の警戒度についての情報が含まれています。

外部への情報漏えいは、システム データやデバッグ情報がプログラムからソケットまたはネットワーク接続を経由してリモートのマシンに送られる場合に発生します。外部的な情報漏洩は、攻撃者にオペレーティング システム、フル パス名、ユーザー名の存在、または設定ファイルの場所などに関する特定のデータを開示する原因となり、攻撃者からのアクセスがより難しい内部的な情報漏洩に比べて深刻な事態を引き起こします。

例 1: 次のコードでは、HTTP レスポンスで例外情報が漏洩されます。

protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
    ...
    PrintWriter out = res.getWriter();
    try {
        ...
    } catch (Exception e) {
      out.println(e.getMessage());
    }
}

この情報はリモート ユーザーに開示される可能性があります。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

情報漏洩は、モバイル コンピューティング環境でも懸念事項です。モバイル プラットフォームでは、あちこちのソースからアプリケーションがダウンロードされ、同じデバイス上で一緒に実行されます。このため、たとえばバンキング アプリケーションのすぐそばでマルウェアを実行するなどの可能性が高くなるので、アプリケーションの開発者は、同じデバイスで実行されている他のアプリケーションに送信するメッセージにどの情報を含めるかについて十分注意する必要があります。

例 2: 次のコードでは、キャッチされた例外のスタックトレースをすべての登録済み Android 受信者に開示します。

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

これは、モバイル環境に特有の別のシナリオです。現在、大半のモバイルデバイスは NFC (Near-Field Communication) プロトコルを実装しており、無線通信を使用するデバイス間で迅速に情報を共有します。NFC は、デバイスを相互に近づけるかまたは接触させることで機能します。NFC の通信範囲は数センチメートルに限定されますが、NFC 自体ではセキュリティをともなう通信を確立できないので、盗聴、データ改変など各種の攻撃が可能です。

例 3: Android プラットフォームでは NFCがサポートされます。次のコードは、通信範囲内にある他のデバイスにプッシュされるメッセージを作成します。

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

NDEF (NFC Data Exchange Format) メッセージには、入力済みデータ、URI、またはカスタムのアプリケーション ペイロードが含まれます。メッセージにアプリケーションについての情報、たとえば名前、MIME タイプ、デバイスソフトウェアのバージョンなどが含まれていると、その情報が盗聴者に漏れる可能性があります。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 以下のコードは例外を標準エラーストリームに書き込みます。

var http = require('http');
...

http.request(options, function(res){
  ...
}).on('error', function(e){
  console.log('There was a problem with the request: ' + e);
});
...

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 次のコードでは、例外を標準エラー ストリームに書き込みます。

try {
    ...
} catch (e: Exception) {
    e.printStackTrace()
}

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

情報漏洩は、モバイル コンピューティング環境でも懸念事項です。

例 2: 次のコードでは、Android プラットフォーム上でキャッチされた例外のスタックトレースのログを作成します。

...
try {
  ...
} catch (e: Exception) {
    Log.e(TAG, Log.getStackTraceString(e))
}
...

内部的な情報漏えいは、システムデータやデバッグ情報がローカルのファイル、コンソール、または画面にロギングや印刷を通じて送信される時に発生します。
例 1: 下記のコードは、システム情報をシステム ログに漏えいします。

...
NSString* deviceID = [[UIDevice currentDevice] name];

NSLog(@"DeviceID: %@", deviceID);
...

モバイルの世界では、デバイスの紛失や盗難が起きた場合、システム情報の保守に関する他の領域の懸念が生じます。iOS デバイスを所有すると、攻撃者は USB によってデバイスに接続し、大量のデータにアクセスすることが可能になります。iOS Property Lists (plists) などのファイルや SQLite データベースに簡単にアクセスできるため、個人情報が漏洩する可能性が生じます。全般的な規則として、個人情報を保護せずにファイル システム上に格納しないでください。

例 2: 次のコードでは、deviceID エントリをデフォルトのユーザー リストに追加し、直ちに plist ファイルに格納します。

...
NSString* deviceID = [[UIDevice currentDevice] name];

[defaults setObject:deviceID forKey:@"deviceID"];
[defaults synchronize];
...

Example 2 のコードでは、モバイル デバイスのシステム情報が、そのデバイス上に格納されている保護されていない plist ファイルに格納されます。開発者の多くは、plist ファイルをあらゆるデータの安全な格納先として信頼しがちですが、plist ファイルはデバイスを保持しているあらゆるユーザーが読み取ることができるため、特にシステム情報およびプライバシーに関わる場合は盲目的に信頼しないでください。

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。このエラーメッセージにより、システムがどのような攻撃に対して脆弱か、攻撃者に正確に伝わる可能性もあります。たとえば、あるデータベースのエラーメッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラーメッセージがシステムに関する間接的な手がかりを示すことがあります。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 以下のコードは例外を標準エラーストリームに書き込みます。

<?php
    ...
    echo "Server error! Printing the backtrace";
    debug_print_backtrace();
    ...
?>

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 次のコードは例外を標準出力ストリームに書き込みます。

    try:
        ...
    except:
        print(sys.exc_info()[2])

この情報はコンソールにダンプされます。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 以下のコードは例外を標準エラーストリームに書き込みます。

...
begin
  log = Logger.new(STDERR)
  ...
rescue Exception
    log.info("Exception: " + $!)
...
end

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。当然、Example 1 には、特定のタイプのエラー/例外ではなくルート Exception を救済するという問題もあります。つまり、すべての例外がキャッチされるため、他にも不用意で副次的な状況が発生する可能性があります。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例 1: 以下のコードはシステム情報を標準出力ストリームに出力します。

...
println(Properties.osName)
...

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。場合によってはエラー メッセージから、システムが正確にはどのタイプの攻撃に対して脆弱なのかを攻撃者が把握してしまいます。たとえば、あるデータベースのエラー メッセージから、アプリケーションが SQL インジェクション攻撃に対して脆弱であることがわかる場合があります。また、他のエラー メッセージがシステムに関する間接的な手がかりを示すことがあります。Example 1 では、漏洩情報に、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、およびプログラムの設定に対する管理者の警戒度についての情報が含まれています。

内部的な情報漏えいは、システムデータやデバッグ情報がローカルのファイル、コンソール、または画面にロギングや印刷を通じて送信される時に発生します。



モバイルの世界では、デバイスの紛失や盗難が起きた場合、システム情報の保守に関する他の領域の懸念が生じます。iOS デバイスを所有すると、攻撃者は USB によってデバイスに接続し、大量のデータにアクセスすることが可能になります。iOS Property Lists (plists) などのファイルや SQLite データベースに簡単にアクセスできるため、個人情報が漏洩する可能性が生じます。全般的な規則として、個人情報を保護せずにファイル システム上に格納しないでください。

例: 次のコードはデバイス ID をシステム ログに出力します。

let deviceName = UIDevice.currentDevice().name
...
NSLog("Device Identifier: %@", deviceName)

システム構成により異なりますが、この情報は、コンソールへのダンプ、ログファイルへの書き込み、およびユーザーへの開示が可能です。このエラーメッセージにより、システムがどのような攻撃に対して脆弱か、攻撃者に正確に伝わる可能性もあります。たとえば、あるデータベースのエラーメッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラーメッセージがシステムに関する間接的な手がかりを示すことがあります。

内部的な情報漏えいは、システム データやデバッグ情報がローカルのファイル、コンソール、または画面に印刷やロギングによって送信されるときに発生します。

例: 次のコードは、ASPError オブジェクトを Microsoft Script Debugger などのスクリプトデバッガーに送ります。

...
Debug.Write Server.GetLastError()
...

場合によってはエラーメッセージから、システムがどのような攻撃に対して脆弱か攻撃者が正確に把握してしまいます。たとえば、あるデータベースのエラーメッセージから、アプリケーションが SQL Injection 攻撃に対して脆弱であることがわかる場合があります。また、他のエラーメッセージが、オペレーティングシステムのタイプ、システムにインストールされているアプリケーション、プログラムの設定に対する管理者の警戒度の情報など、システムに関する間接的な手がかりを示すことがあります。

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

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

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

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

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

例: 次のメソッドは、開いたファイルハンドルを閉じていません。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 攻撃を開始できる可能性があります。

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

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

攻撃者が値を指定し、アプリケーションがそれを使用してどのクラスをインスタンス化するかや、どのメソッドを呼び出すかを決定できてしまうと、攻撃者はアプリケーションを介して予期せぬ制御フロー パスを作成できてしまう可能性があります。これにより、攻撃者が認証チェックやアクセス制御チェックをすり抜けたり、アプリケーションが予期しない方法で動作したりする可能性があります。
例: 次のアクション メソッドは、外部 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 チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

例: プログラマは、リフレクションを使用して、コマンド ディスパッチャを実装することがよくあります。次の例は、リフレクションを使用しないコマンドディスパッチャです。

...
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 New 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 New 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 の失敗を犯しやすくなります。

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

このような状況が発生した場合、攻撃者がアプリケーション パスやライブラリ パスが示す場所にファイルをアップロードすることが可能になると、致命的な結果を招きます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例: プログラマがリフレクション 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 チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例: プログラマがリフレクション 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 チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例: プログラマがリフレクション 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 チェックを回避したり、本来意図されていない行動をアプリケーションにさせたりすることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

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

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 チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

攻撃者がファイルをアプリケーションのクラスパス上に表示される場所にアップロードできる、または新しいエントリをアプリケーションのクラスパス上に追加できる場合、これは最悪のシナリオになってしまいます。このいずれかの条件下では、攻撃者はリフレクションを使用して、悪意あるものである可能性が高い新しい動作をアプリケーションに持ち込むことができます。
例: プログラマがリフレクション 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 チェックなどを回避できるので、本来意図されていない行動をアプリケーションにさせることができます。特定のメソッドまたはコンストラクタに渡される引数の制御さえできれば、狡猾な攻撃者は攻撃を仕掛けるきっかけを得られる可能性があります。

例: プログラマが CallByNam を使用する一般的な理由は、独自のコマンドディスパッチャを実装するためです。次の例は、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 の失敗を犯しやすくなります。

次の場合に XML External Entity (XXE) injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データは XML 文書内の DTD (Document Type Definition) の<ENTITY> 要素に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者にユーザー加工前の XML への書き込みができる場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。最も害のない場合でも、攻撃者はネスト化されたエンティティ参照を挿入し、XML パーサーに大量の CPU リソースを消費させ続けることができます。より悪質な XML External Entity Injection の場合、攻撃者は、ローカルの File System リソースの内容を開示したり内部ネットワーク リソースの存在を明らかにしたりする XML 要素を追加できる可能性があります。

例 1: XXE 攻撃に対して脆弱な Objective-C コードの例を次に示します。

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

次のような XML で攻撃者が rawXml を制御できると考えてみます。

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

XML がサーバーによって評価される場合、<foo> 要素には boot.ini ファイルの内容が含まれます。

XML External Entities 攻撃は、処理の際に動的にドキュメントを作成する XML の機能を利用しています。XML エンティティは、特定のリソースから動的にデータを取り込むことができます。外部エンティティでは、XML ドキュメントに外部 URI からのデータを含めることができます。別途設定をしない限り、外部エンティティは XML パーサーに URI で指定されたリソース (たとえば、ローカルマシンまたはリモートシステム上のファイル) へのアクセスを強制します。この動作は、アプリケーションを XML External Entity (XXE) 攻撃にさらします。この攻撃は、ローカルシステムサービスの拒否、ローカルマシン上のファイルへの未許可のアクセス、リモートマシンのスキャン、および、リモートシステムのサービスの拒否をするのに使用されます。

次の XML ドキュメントは、XXE 攻撃の例です。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

この例では、XML パーサーがエンティティを /dev/random ファイルの内容に置き換えようとすると、サーバー (UNIX システム) がクラッシュする可能性があります。

XML External Entity 攻撃は、実行時にドキュメントを動的に作成する XML の機能を利用しています。XML エンティティは、特定のリソースからデータを動的に取り込めるようにします。外部エンティティでは、XML ドキュメントに外部 URI からのデータを含めることができます。別途設定をしない限り、外部エンティティは XML パーサーに対し、URI で指定されたリソース (ローカル マシン上またはリモート システム上のファイルなど) へのアクセスを強制します。この動作は、アプリケーションを XML External Entity (XXE) 攻撃にさらします。これにより攻撃者は、ローカル システムのサービス妨害、ローカル マシン上のファイルへの不正アクセス、リモート マシンのスキャン、リモート システムのサービス妨害を実行できるようになります。


例 1: 次の XML ドキュメントは、XXE 攻撃の例を示しています。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

この例では、XML パーサーがエンティティを /dev/random ファイルの内容に置き換えようとすると、サーバー (UNIX システム上) がクラッシュする可能性があります。

次の場合に XML External Entity (XXE) injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. XML 文書内の DTD (Document Type Definition) の <ENTITY> 要素にデータが書き込まれた場合。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者にユーザー加工前の XML への書き込みができる場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。最も害のない場合でも、攻撃者はネスト化されたエンティティ参照を挿入し、XML パーサーに大量の CPU リソースを消費させ続けることができます。より悪質な XML External Entity Injection の場合、攻撃者は、ローカルの File System リソースの内容を開示したり内部ネットワーク リソースの存在を明らかにしたりする XML 要素を追加できる可能性があります。

例 1: XXE 攻撃に対して脆弱なコードの例を次に示します。

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

次のような XML で攻撃者が rawXml を制御できると考えてみます。

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

XML がサーバーによって評価される場合、<foo> 要素には boot.ini ファイルの内容が含まれます。

次の場合に XML External Entity (XXE) injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. このデータは、XML 文書に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者にユーザー加工前の XML への書き込みができる場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。最も害のない場合でも、攻撃者はネスト化されたエンティティ参照を挿入し、XML パーサーに大量の CPU リソースを消費させ続けることができます。より悪質な XML External Entity Injection の場合、攻撃者はローカルの File System リソースの内容を開示したり、内部ネットワーク リソースの存在を明らかにしたり、バックエンド コンテンツ自体を危険にさらす XML 要素を追加できる可能性があります。

例 1: XXE 攻撃に対して脆弱なコードの例を次に示します。

攻撃者は以下のコードへの XML 入力を制御できるものと仮定します。

...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...

ここで、攻撃者からExample 2 のコードに以下の XML が渡されると仮定してください。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

この XML を処理するとき、<foo> 要素のコンテンツにはシステムの boot.ini ファイルのコンテンツが埋め込まれます。攻撃者は、データを盗み出したり、ネットワーク リソースの存在に関する情報を取得するために、クライアントに返される XML 要素を利用することができます。

XML External Entities 攻撃は、実行時にドキュメントを動的に作成する XML の機能を利用しています。XML エンティティは、特定のリソースからデータを動的に取り込めるようにします。外部エンティティでは、XML ドキュメントに外部 URI からのデータを含めることができます。別途設定をしない限り、外部エンティティは XML パーサーに対し、URI で指定されたリソース (ローカル マシン上またはリモート システム上のファイルなど) へのアクセスを強制します。この動作は、アプリケーションを XML External Entity (XXE) 攻撃にさらします。これは攻撃者が、ローカル システムのサービス妨害、ローカル マシン上のファイルへの未許可のアクセス、リモート マシンのスキャン、リモート システムのサービス妨害をするのに使用します。


例 1: 次の XML ドキュメントは、XXE 攻撃の例です。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

この例では、XML パーサーがエンティティを /dev/random ファイルの内容に置き換えようとすると、サーバー (UNIX システム) がクラッシュする可能性があります。

XML External Entities 攻撃は、処理の際に動的にドキュメントを作成する XML の機能を利用しています。XML エンティティは、特定のリソースから動的にデータを取り込むことができます。外部エンティティでは、XML ドキュメントに外部 URI からのデータを含めることができます。別途設定をしない限り、外部エンティティは XML パーサーに URI で指定されたリソース (たとえば、ローカルマシンまたはリモートシステム上のファイル) へのアクセスを強制します。この動作は、アプリケーションを XML External Entity (XXE) 攻撃にさらします。この攻撃は、ローカルシステムサービスの拒否、ローカルマシン上のファイルへの未許可のアクセス、リモートマシンのスキャン、および、リモートシステムのサービスの拒否をするのに使用されます。

次の XML ドキュメントは、XXE 攻撃の例です。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

例の XML ドキュメントでは、/etc/passwd のコンテンツを読み込み、それらをドキュメントに含めます。

例 1: 次のコードでは、安全でない XML パーサーを使用して HTTP リクエストからの信頼されていない入力を処理します。

def readFile() = Action { request =>
    val xml = request.cookies.get("doc")
    val doc = XMLLoader.loadString(xml)
    ...
}

次の場合に XML External Entity (XXE) injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データは XML 文書内の DTD (Document Type Definition) の<ENTITY> 要素に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者にユーザー加工前の XML への書き込みができる場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。最も害のない場合でも、攻撃者はネスト化されたエンティティ参照を挿入し、XML パーサーに大量の CPU リソースを消費させ続けることができます。より悪質な XML External Entity Injection の場合、攻撃者は、ローカルの File System リソースの内容を開示したり内部ネットワーク リソースの存在を明らかにしたりする XML 要素を追加できる可能性があります。

例 1: XXE 攻撃に対して脆弱なコードの例を次に示します。

func parseXML(xml: String) {
    parser = NSXMLParser(data: rawXml.dataUsingEncoding(NSUTF8StringEncoding)!)
    parser.delegate = self
    parser.shouldResolveExternalEntities = true
    parser.parse()
}

XML が以下のようになっている rawXml コンテンツを攻撃者が制御できる場合を考えてみましょう。

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

XML がサーバーによって評価される場合、<foo> 要素には boot.ini ファイルの内容が含まれます。

次の場合に XML Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. このデータは、XML 文書に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者が XML に書き込みが可能な場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。攻撃者は余分なタグを挿入して、XML パーサーで例外を発生させることもできます。悪質な場合、攻撃者は認証情報を変更する XML 要素を追加したり、XML を使用する e コマース データベースで価格を改変する可能性があります。また、XML Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1:

以下の XML の shoes を攻撃者が制御できる場合を考えてみましょう。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

ここで、この XML がバックエンドの Web サービスリクエストに追加され、一足の靴が注文されるとします。攻撃者がリクエストを変更して、shoes を shoes</item><price>1.00</price><item>shoes に置き換えるとします。新しい XML は以下のようになります。

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

SAX パーサーを使用すると、2 番目の <price> の値により最初の <price> タグの値が上書きされます。これにより、攻撃者は $100 の靴を $1 で購入できます。

次の場合に XML Ｉnjection が発生します。

1.信頼できないソースからデータがプログラムに入力された場合。

2.このデータは、XML 文書に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者が XML に書き込みが可能な場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。攻撃者は余分なタグを挿入して、XML パーサーで例外を発生させることもできます。悪質な場合、攻撃者は認証情報を変更する XML 要素を追加したり、XML を使用する e コマース データベースで価格を改変する可能性があります。また、XML Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1:

以下の XML の shoes を攻撃者が制御できる場合を考えてみましょう。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

ここで、この XML がバックエンドの Web サービス リクエストに追加され、一足の靴が注文されるとします。攻撃者がリクエストを変更して、shoes を shoes</item><price>1.00</price><item>shoes に置き換えるとします。新しい XML は以下のようになります。

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

SAX パーサーを使用すると、2 番目の <price> の値により最初の <price> タグの値が上書きされます。これにより、攻撃者は $100 の靴を $1 で購入できます。

次の場合に XML Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. このデータは、XML 文書に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者が XML に書き込みが可能な場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。攻撃者は余分なタグを挿入して、XML パーサーで例外を発生させることもできます。悪質な場合、攻撃者は認証情報を変更する XML 要素を追加したり、XML を使用する e コマース データベースで価格を改変する可能性があります。また、XML Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1:

以下の XML の shoes を攻撃者が制御できる場合を考えてみましょう。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

ここで、この XML がバックエンドの Web サービスリクエストに追加され、一足の靴が注文されるとします。攻撃者がリクエストを変更して、shoes を shoes</item><price>1.00</price><item>shoes に置き換えるとします。新しい XML は以下のようになります。

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

SAX パーサーを使用すると、2 番目の <price> の値により最初の <price> タグの値が上書きされます。これにより、攻撃者は $100 の靴を $1 で購入できます。

次の場合に XML Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. このデータは、XML 文書に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者が XML に書き込みが可能な場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。攻撃者は余分なタグを挿入して、XML パーサーで例外を発生させることもできます。悪質な場合、攻撃者は認証情報を変更する XML 要素を追加したり、XML を使用する e コマース データベースで価格を改変する可能性があります。また、XML Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1:

以下の XML の shoes を攻撃者が制御できる場合を考えてみましょう。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

ここで、この XML がバックエンドの Web サービスリクエストに追加され、一足の靴が注文されるとします。攻撃者がリクエストを変更して、shoes を shoes</item><price>1.00</price><item>shoes に置き換えるとします。新しい XML は以下のようになります。

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

これにより、攻撃者は $100 の靴を $1 で購入できてしまうことがあります。

次の場合に XML Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。


2. このデータは、XML 文書に書き込まれます。

アプリケーションは、通常、XML を使用してデータを保存したりメッセージを送信したりします。XML がデータの保存に使用される場合、XML 文書はデータベースのように扱われ、重要な情報が含まれる場合があります。XML メッセージは、Web サービスでも頻繁に使用されており、重要な情報を送信するときにも使用される場合があります。XML メッセージは、認証情報を送信するときに使用されることさえあります。

攻撃者が XML に書き込みが可能な場合、XML 文書およびメッセージのセマンティクスが改変される場合があります。攻撃者は余分なタグを挿入して、XML パーサーで例外を発生させることもできます。悪質な場合、攻撃者は認証情報を変更する XML 要素を追加したり、XML を使用する e コマース データベースで価格を改変する可能性があります。また、XML Injection により、Cross-Site Scripting や Dynamic Code Evaluation が引き起こされる場合もあります。

例 1:

以下の XML の shoes を攻撃者が制御できる場合を考えてみましょう。

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

ここで、この XML がバックエンドの Web サービスリクエストに追加され、一足の靴が注文されるとします。攻撃者がリクエストを変更して、shoes を shoes</item><price>1.00</price><item>shoes に置き換えるとします。新しい XML は以下のようになります。

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

SAX パーサーを使用すると、2 番目の <price> の値により最初の <price> タグの値が上書きされます。これにより、攻撃者は $100 の靴を $1 で購入できます。