ほとんどの現代言語（何らかの方法で解釈される）には、ある種の評価関数があります。このような関数は任意の言語コードを実行します。ほとんどの場合、文字列としてメイン引数として渡されます（異なる言語はeval関数により多くの機能を追加する場合があります）。

特にサーバー側のソフトウェアでは、悪意のあるコードをプロセスに実行させる可能性があるため、ユーザーがこの機能を実行することを許可しないことを理解しています（編集、つまり任意のユーザーからの任意の入力を直接または間接的に取得して渡されますeval）。そのようにして、チュートリアルとコミュニティはevalを使用しないように指示します。ただし、evalが便利で使用される場合が多くあります。

• ソフトウェア要素へのカスタムアクセスルール（IIRC OpenERPには、ir.rule動的なPythonコードを使用できるオブジェクトがあります）。
• カスタム計算および/または基準（OpenERPには、カスタムコード計算を可能にするようなフィールドがあります）。
• OpenERPレポートパーサー（はい、私はあなたをOpenERPのものでおかしくしていることを知っています...しかし、それは私が持っている主な例です）。
• 一部のRPGゲームでのスペルエフェクトのコーディング。

したがって、それらは適切に使用されている限り、有効に使用されます。主な利点は、この機能により、管理者が追加のファイルを作成してそれらを含めることなくカスタムコードを記述できることです（ただし、eval機能を使用するほとんどのフレームワークには、ファイル、モジュール、パッケージなどを指定して読み込む方法があります）。

ただし、大衆文化ではevalは悪です。システムに侵入するようなものが思い浮かびます。

ただし、ユーザーが何らかの方法でアクセスすると有害になる可能性のある他の機能があります：リンク解除、読み取り、書き込み（ファイルのセマンティクス）、メモリ割り当てとポインター演算、データベースモデルアクセス（SQLインジェクタブルのケースを考慮しない場合でも）。

だから、基本的には、ほとんどの時間を任意のコードが書かれていませんが、適切かどうか見て適切に（リソース、ユーザ、環境、...）は、コードが悪であるとさえ経済的影響につながることができます。

しかし、eval関数には特別なものがあります（言語に関係なく）。

質問：他の危険な要素に同じ注意を払うのではなく、この恐怖が大衆文化の一部になるという歴史的な事実はありますか？

evalそれ自体で機能が悪ではない、と私はあなたが作っているとは思わないという微妙な点があります：

プログラムが任意のユーザー入力を実行できるようにするのは悪い

evalある種の関数を使用するコードを記述しましたが、それは安全でした。プログラムとパラメーターはハードコードされていました。場合によっては、プログラムが必要とすることを行うための言語またはライブラリ機能がなく、シェルコマンドを実行することが短いパスです。「これを数時間でコーディングしなければなりませんが、Java / .NET / PHP /なんでもコードを書くのに2日かかります。またはeval5分でできます。」

ユーザー特権によって、または「安全な」画面の背後でロックダウンされている場合でも、ユーザーが必要なものを実行できるようにしたら、攻撃ベクトルを作成します。毎週、ランダムなCMS、ブログソフトウェアなどに、セキュリティホールがパッチされ、攻撃者がこのようなホールを悪用できるようになっています。あなたはに使用できる関数へのプロテクトアクセスするソフトウェアスタック全体に依存しているrm -rf /か、他の何か致命的な（：そのコマンドが成功する可能性は低いですが、失敗します後に損傷のビットを引き起こします）。

この恐れが他の危険な機能に同じ注意を払うのではなく、大衆文化の一部になるという歴史的な事実はありますか？

はい、歴史的な先例があります。リモートの攻撃者が任意のコードを実行することを可能にするさまざまなソフトウェアで長年にわたって修正されてきた多数のバグにより、その考えevalはほとんど支持されなくなりました。現代の言語とライブラリにはeval、重要性が低くなる豊富な機能セットがあり、これは偶然ではありません。機能を使いやすくし、悪用のリスクを軽減します。

人気のある言語の多くの潜在的に安全でない機能に多くの注意が払われています。注目を集めるかどうかは主に意見の問題ですが、eval機能には確かに、わかりやすい証明可能なセキュリティ問題があります。1つは、シェルの組み込みコマンドや標準の外部プログラム（rmまたはなどdel）を含むオペレーティングシステムコマンドを実行できることです。2つは、他のエクスプロイトと組み合わせて、攻撃者が独自の実行可能ファイルまたはシェルスクリプトをアップロードし、それをソフトウェア経由で実行し、ほとんど何でも起こる可能性があります（どれも良いことではありません）。

これは難しい問題です。ソフトウェアは複雑であり、ソフトウェアスタック（LAMPなど）は、複雑な方法で相互にやり取りする複数のソフトウェアです。このような言語機能の使用方法に注意し、ユーザーが任意のコマンドを実行できないようにしてください。

その一部は、単にニュアンスが難しいということです。goto、publicフィールド、SQLクエリの文字列補間、evalを使用しないなどのことを言うのは簡単です。これらのステートメントは、どのような状況においても、それらを使用する理由は決してないと言っていると理解すべきではありません。しかし、一般的な経験則としてそれらを避けることは良い考えです。

Evalは、いくつかの一般的な問題を組み合わせているため、非常に推奨されていません。

第一に、インジェクション攻撃を受けやすいです。ここでは、ユーザーが制御したデータをコードに挿入すると、任意のコードが誤って挿入される可能性が高いという点で、SQLインジェクションに似ています。

第二に、初心者はevalを使用して、構造の悪いコードを回避する傾向があります。初心者のコーダーは、次のようなコードを作成できます。

x0 = "hello"
x1 = "world"
x2 = "how"
x3 = "are"
x4 = "you?"
for index in range(5):
   print eval("x" + index)

これは機能しますが、実際にはこの問題を解決する間違った方法です。明らかに、リストを使用するほうがずっと良いでしょう。

第三に、evalは通常非効率的です。プログラミング言語の実装を高速化するために多くの努力が費やされています。ただし、evalを高速化することは難しく、通常、evalを使用するとパフォーマンスに悪影響が生じます。

したがって、evalは悪ではありません。evalは悪だと言えるかもしれません。初心者のコーダーはevalから厳密に離れる必要があります。何をしたいにしても、evalはほぼ間違いなく間違ったソリューションです。特定の高度なユースケースでは、evalは理にかなっており、使用する必要がありますが、明らかに落とし穴に注意してください。

要するに、「任意のコード実行」は「何でもできる」ための技術的な話です。誰かがあなたのコードで任意のコードの実行を悪用できる場合、これは文字通り可能な限り最悪のセキュリティ脆弱性です。それは彼らがあなたのシステムでできることは何でもできることを意味するからです。

「その他の有害な可能性のあるバグ」には制限がある場合があります。つまり、定義により、任意のコード実行よりも害が少ない可能性があります。

実用的で理論的な理由があります。

実際的な理由は、それが頻繁に問題を引き起こすことを観察することです。evalが良い解決策をもたらすことはまれであり、evalが存在しないふりをして問題に別のアプローチをした場合、最終的にはより良い解決策が得られる悪い解決策になることがよくあります。したがって、単純化されたアドバイスはそれを無視することです。単純化されたアドバイスを無視したい場合は、単純化されたアドバイスが適用できない理由と一般的な理由を十分に理解してください。落とし穴はあなたに影響しません。

より理論的な理由は、良いコードを書くのが難しい場合、良いコードを書くコードを書くのがさらに難しいからです。evalを使用している場合でも、文字列を貼り付けてSQLステートメントを生成している場合でも、JITコンパイラーを作成している場合でも、多くの場合、あなたがしようとしていることは予想以上に困難です。悪意のあるコードインジェクションの可能性は問題の大きな部分の1つですが、それ以外に、コードが実行時まで存在しない場合、コードが正しいことを知ることは一般的に困難です。したがって、単純化されたアドバイスは、「パラメーター化されたSQLクエリを使用する」、「evalを使用しない」ということを自分で簡単に保つことです。

スペルエフェクトを例にとると、ゲームデザイナーがC ++（またはその他）よりも簡単な言語でスペルエフェクトを説明できるようにするために、ゲームにLua（またはその他）のコンパイラーまたはインタープリターを組み込むことが1つあります。ゲームまたはDLCまたはwhat-have-youに記述およびテストされ、含まれているコードの評価のみを行う場合、「evalの問題」のほとんどは当てはまりません。それは単に言語を混ぜているだけです。大きな問題は、その場でLua（またはC ++、またはSQL、またはシェルコマンド、その他）を生成しようとして混乱することです。

いいえ、明らかな歴史的事実はありません。

evalの悪は最初から見るのは明白です。他の機能はやや危険です。ユーザーはデータを削除できます。見るべきではないデータを見ることができます。人々はすべきでないデータを書くことができます。そして、なんらかの方法でユーザー入力を検証せずに、それらのほとんどを行うことができます。

evalを使用すると、五角形をハックして、あなたがやったように見せることができます。彼らはあなたのキーストロークを調べてパスワードを取得できます。チューリングの完全な言語を想定して、彼らは文字通りあなたのコンピューターができることなら何でもできます。

また、入力を検証することはできません。任意の自由形式の文字列です。検証する唯一の方法は、問題の言語のパーサーとコード分析エンジンを構築することです。幸運を祈ります。

私はそれが次の側面に要約されると思う：

• 必要性
• （ガード付き）使用法
• アクセス
• 検証可能性
• 多段階攻撃

必要性

こんにちは、この非常にクールな画像編集ツール（$ 0.02で入手可能）を作成しました。画像を開いた後、画像に多数のフィルターを渡すことができます。Python（アプリケーションを記述したプログラム）を使用して自分でスクリプトを作成することもできます。私はevalあなたの入力に使用し、あなたが立派なユーザーであることを信頼します。

（後）

それを買ってくれてありがとう。ご覧のとおり、私が約束したとおりに機能します。ああ、あなたは画像を開きたいですか？いいえ、できません。このread方法はやや安全ではないため、使用しません。保存しますか？いいえ、使用しませんwrite。

私が言いたいのは、ほとんどの基本的なツールの読み取り/書き込みが必要だということです。あなたのすごいゲームのハイスコアを保存するのと同じです。

読み取り/書き込みがなければ、画像エディターは役に立ちません。なしeval？そのためのカスタムプラグインを作成します。

（ガード付き）使用法

多くのメソッドは潜在的に危険です。たとえば、readとなどwrite。一般的な例は、名前を指定して特定のディレクトリから画像を読み取ることができるWebサービスです。ただし、実際には「名前」はシステム上の任意の有効な（相対）パスにすることができ、イメージだけでなく、Webサービスがアクセスできるすべてのファイルを読み取ることができます。この単純な例を乱用することを「パストラバーサル」と呼びます。アプリでパストラバーサルが許可されている場合、それは悪いことです。readパストラバーサルのための防御なしでは悪と呼ばれることがWELできます。

ただし、他の場合、の文字列readは完全にプログラマーの制御下にあります（ハードコーディングされている可能性があります）その場合、を使用することはほとんど悪ではありませんread。

アクセス

次に、別の簡単な例を使用しevalます。

Webアプリのどこかに、動的コンテンツが必要です。管理者が実行可能なコードを入力できるようにします。管理者は信頼できるユーザーであるため、理論的には問題ありません。管理者以外から送信されたコードを実行しないようにしてください。大丈夫です。

（つまり、あなたがその素晴らしい管理者を解雇したが、彼のアクセスを取り消すのを忘れるまでです。今、あなたのウェブアプリはゴミ箱に捨てられます）。

検証可能性。

重要なもう1つの側面は、ユーザー入力の検証がいかに簡単かということです。

読み取り呼び出しでユーザー入力を使用しますか？読み取り呼び出しの入力に悪意のあるものが含まれていないことを（非常に）確認してください。パスを正規化し、開いているファイルがメディアディレクトリにあることを確認します。これで安全です。

書き込み呼び出しでのユーザー入力？同じ！

SQLインジェクション？それをエスケープするか、パラメータ化されたクエリを使用すれば安全です。

評価？eval通話に使用されている入力をどのように検証しますか？あなたは非常に一生懸命働くことができますが、それを安全に機能させるのは本当に不可能です。

多段階攻撃

現在、ユーザー入力を使用するたびに、それを使用する利点と危険性を比較検討する必要があります。可能な限りその使用を保護します。

eval管理者の例の有能なものをもう一度考えてください。私はあなたに、それはちょっと大丈夫だと言った。

ここで、ユーザーコンテンツ（HTML、XSS）をエスケープするのを忘れた場所が実際にWebアプリにあることを考慮してください。これは、ユーザーがアクセス可能なevalよりも少ない犯罪です。しかし、ユーザーはエスケープされていないユーザーコンテンツを使用して、管理者のWebブラウザーを引き継ぎeval、管理者セッションを通じて有効なBLOBを追加して、再び完全なシステムアクセスを許可できます。

（XSSの代わりにSQLインジェクションで同じ多段階攻撃を行うことができます。または、を使用する代わりに、実行可能なコードを置き換える任意のファイル書き込みを行いますeval）

この機能がまったく機能するためには、プログラム全体の内部状態への完全なアクセスを可能にする反射層を維持する必要があることを意味します。

インタープリター言語の場合、インタープリターの状態を使用するだけで簡単です。JITコンパイラーと組み合わせると、複雑さが大幅に増加します。

なしevalでは、JITコンパイラは多くの場合、スレッドのローカルデータが他のコードからアクセスされないことを証明できるため、アクセスの順序を変更し、ロックを省略し、頻繁に使用されるデータを長時間キャッシュすることは完全に受け入れられます。別のスレッドがevalステートメントを実行する場合、実行中のJITコンパイル済みコードをそれと同期する必要がある場合があるため、JIT生成コードには、適切な時間内に最適化されていない実行に戻るフォールバックメカニズムが必要になります。

この種のコードは、多くの微妙で再現が難しいバグを抱えている傾向があり、同時にJITコンパイラーの最適化にも制限を設けています。

コンパイルされた言語の場合、トレードオフはさらに悪化します：ほとんどの最適化は禁止されており、広範なシンボル情報とインタープリターを保持する必要があるため、追加の柔軟性は一般に価値がありません-内部インターフェイスへのインターフェースを定義することはしばしばより簡単ですたとえば、スクリプトビューとコントローラーにプログラムのモデルへの同時アクセスを与えることによる構造。

私は、ポインター演算よりも悪であるevalと考えられている前提、または直接メモリおよびファイルシステムアクセスよりも危険であると考えられている前提を拒否します。私はそれを信じる賢明な開発者を知りません。さらに、ポインター算術演算/直接メモリーアクセスをサポートする言語は、通常、その逆もサポートしていません。そのため、このような比較がどれほど頻繁に関連するかは確かです。eval

しかし、JavaScriptでサポートされているという単純な理由evalにより、よりよく知られている脆弱性である可能性があります。JavaScriptは、直接メモリやファイルシステムへのアクセスのないサンドボックス化された言語であるため、言語実装自体の弱点を除いて、これらの脆弱性はありません。Evalしたがって、任意のコード実行の可能性を開くため、言語の最も危険な機能の1つです。C / C ++よりもJavaScriptで開発する開発者の方が多いと思うのでeval、大部分の開発者にとってバッファオーバーフローよりも注意することが重要です。

真面目なプログラマーは、Evalを「悪」だとは思わないでしょう。他のツールと同様、単なるプログラミングツールです。この機能に対する恐怖（もし恐れがある場合）は、大衆文化とは関係ありません。これは単純に危険なコマンドであり、しばしば誤用され、深刻なセキュリティホールをもたらし、パフォーマンスを低下させる可能性があります。私自身の経験から、他の方法では安全かつ効率的に解決できないプログラミングの問題に遭遇することはめったにないと思います。evalを使用する可能性が最も高いプログラマは、安全に使用する資格がおそらく最も低いプログラマです。

そうは言っても、evalの使用が適切な言語があります。Perlが思い浮かびます。しかし、個人的には、構造化された例外処理をネイティブでサポートする他のより現代的な言語では必要になることはほとんどありません。

あなたはあなたの質問の次の部分でそれを非常によくカバーしていると思います（強調鉱山）：

それらが適切に使用されている限り、それらは良い用途を持っています

適切に使用する可能性のある95％の人にとっては、それはすべてうまくいきます。しかし、常にそれを適切に使用しない人がいます。それらのいくつかは経験不足と能力不足に陥り、残りは悪意があります。

境界を押し広げてセキュリティホールを見つけたいと思う人は常にいるでしょう-善人も悪人もいます。

それの歴史的事実の側面に関しては、eval型関数は本質的に、以前は人気のあるWeb CMS、Joomla！で悪用されていた任意のコード実行を可能にします 。Joomla！世界中の250万以上のサイトに電力を供給しているため、それらのサイトへの訪問者だけでなく、ホストされているインフラストラクチャや悪用されたサイト/企業の評判にも大きな損害を与える可能性があります。

Joomla！例は単純な例かもしれませんが、記録されたものです。

使用を思いとどまらせるにはいくつかの正当な理由がありますeval（特定の言語に固有のものもあります）。

• によって使用される環境（字句的および動的）evalは、しばしば驚くべきものです（つまり、あることeval(something here)を行う必要があると思うが、別のことを行い、例外を引き起こす可能性があります）
• 多くの場合、同じことを達成するためのより良い方法があります（構築されたレキシカルクロージャの連結は時々より良い解決策ですが、それはCommon Lisp固有かもしれません）
• 安全でないデータが評価されてしまうのは非常に簡単です（ただし、ほとんどの場合これを防ぐことができます）。

個人的には、それが悪だと言っている限りではありませんがeval、「ここでコードを検討しましたか？」という言葉に沿って、コードレビューでの使用に常に挑戦します。（少なくとも一時的な置き換えを行う時間があれば）、または「ここでevalが本当に最善の解決策であると確信していますか？」（私がしない場合）。

Minsky's Society of Mindの Chapter 6.4で、彼は言う

心が自分自身を見て、何が起こっているのかを追跡する方法が1つあります。脳を2つの部分、AとBに分割します。A脳の入力と出力を現実の世界に接続します。これにより、そこで起こることを感知できます。ただし、B脳を外界に接続しないでください。代わりに、A脳がB脳の世界になるように接続します。

あるプログラム（B）が別のプログラム（A）を書き込むとき、それはメタプログラムとして機能しています。Bの主題はプログラムAです。

Cプログラムがあります。それはあなたの頭の中にプログラムBを書くものです。

危険なのは、悪意を持った人（C '）がこのプロセスに干渉する可能性があるため、SQLインジェクションのようなものが得られることです。

課題は、ソフトウェアをより危険にすることなく、よりスマートにすることです。

あなたはここで良い答えがたくさんあるし、主な理由は、明らかに、任意のコードの実行が悪いmmmkayですが、私は他の人が唯一の端に触れていることを一つの他の要因を追加します。

テキスト文字列から評価されているコードのトラブルシューティングは非常に困難です。通常のデバッグツールはほとんどすぐに使用でき、非常に古いトレースやエコーに限定されます。必要なワンライナーにフラグメントがある場合はそれほど重要ではありませんevalが、経験豊富なプログラマーとしてはおそらくより良いソリューションを見つけることができますが、大規模なコード生成は評価関数潜在的に有用な同盟国になります。