Dynamic Code Evaluation: Code Injection

実行時にユーザーの制御下にある命令を解釈すると、攻撃者が悪意のあるコードを実行できる可能性があります。

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

例 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 コマンドが実行されます。