（スプレッドシートのような機能のために）ユーザーが入力した関数を解析するJavaScriptコードを書いています。私は式解析された可能性はJavaScriptに変換して実行しeval()、結果を得るために、その上に。

しかし、私はeval()それが悪であるのでそれを避けることができる場合は常に使用を避けてきました（そして、正しいかまたは間違って、評価されるコードはユーザーによって変更される可能性があるため、JavaScriptではさらに悪であると常に思っていました）。

それで、いつそれを使用してもよいですか？

私はあなたの質問の前提に対処するために少し時間をとりたいと思います-eval（）は「悪」です。プログラミング言語の人々が使用する「悪」という言葉は、通常「危険」、またはより正確には「単純に見えるコマンドで多くの害を及ぼす可能性がある」を意味します。では、危険なものを使用してもよいのはいつですか。危険が何であるかを知り、適切な予防策を講じているとき。

要点として、eval（）の使用における危険性を見てみましょう。おそらく他のすべてと同じように小さな隠れた危険がたくさんあるでしょうが、2つの大きなリスク-eval（）が悪と見なされる理由-はパフォーマンスとコードインジェクションです。

• パフォーマンス-eval（）はインタープリター/コンパイラーを実行します。コードがコンパイルされている場合、ランタイムの途中で重い可能性のあるコンパイラを呼び出す必要があるため、これは大ヒットです。ただし、JavaScriptは依然としてほとんどの場合インタプリタ言語です。つまり、eval（）を呼び出しても、一般的なケースではパフォーマンスに大きな影響はありません（ただし、以下の具体的なコメントを参照してください）。
• コードインジェクション-eval（）は、昇格された特権でコード文字列を実行する可能性があります。たとえば、administrator / rootとして実行されているプログラムは、ユーザー入力を「rm -rf / etc / important-file」またはそれよりも悪い可能性があるため、eval（）ユーザー入力を望まないでしょう。この場合も、プログラムはユーザー自身のアカウントで実行されているため、ブラウザーのJavaScriptにはそのような問題はありません。サーバー側のJavaScriptがその問題を抱えている可能性があります。

あなたの特定のケースに移ります。私が理解していることから、あなたは自分で文字列を生成しているので、「rm -rf something-important」のような文字列が生成されないように注意すると、コードインジェクションのリスクはありません（ただし、非常に非常に重要です）一般的なケースではこれを確実にすることは困難です）。また、ブラウザーで実行している場合、コードインジェクションはかなり小さなリスクであると私は信じています。

パフォーマンスに関しては、コーディングの容易さに対して重み付けする必要があります。式を解析する場合、別のパーサー（eval（）内のパーサー）を実行するのではなく、解析中に結果を計算することもできます。しかし、eval（）を使用してコーディングする方が簡単な場合があり、パフォーマンスへの影響はおそらく目立ちません。この場合のeval（）は、時間を節約できる可能性のある他のどの関数よりも邪悪ではないようです。

eval()悪ではありません。あるいは、そうであれば、リフレクション、ファイル/ネットワークI / O、スレッド化、IPCが他の言語で「悪」であるのと同じ方法で悪です。

、場合あなたの目的のために、eval()手動の解釈よりも高速である、またはあなたのコードは単純で、またはより明確になります...そして、あなたはそれを使用する必要があります。どちらでもない場合は、すべきではありません。そのような単純な。

ソースを信頼するとき。

JSONの場合、ソースを改ざんすることは多かれ少なかれ困難です。なぜなら、それが制御するWebサーバーからのものだからです。JSON自体にユーザーがアップロードしたデータが含まれていない限り、evalを使用しても大きな欠点はありません。

他のすべての場合では、eval（）に供給する前に、ユーザーが指定したデータが私のルールに準拠するように最大限の努力をします。

本当の人々を手に入れましょう：

1. すべての主要なブラウザーには、組み込みのコンソールがあり、ハッカーになる可能性のあるユーザーが豊富な機能を使用して、任意の値を持つ任意の関数を呼び出すことができます。

2. JavaScriptの2000行をコンパイルするのに0.2秒かかる場合、4行のJSONを評価すると、パフォーマンスはどのように低下​​しますか？

「eval is evil」についてのクロックフォードの説明でさえ弱い。

evalは悪であり、eval関数はJavaScriptの最も誤用されている機能です。それを避ける

クロックフォード自身が言うかもしれないように「この種の声明は不合理な神経症を引き起こす傾向がある。それを買わないでください」。

evalを理解し、いつ役立つかを知ることは、さらに重要です。たとえば、evalは、ソフトウェアによって生成されたサーバー応答を評価するための賢明なツールです。

ところで：Prototype.jsはevalを5回直接呼び出します（evalJSON（）とevalResponse（）を含む）。jQueryはそれをparseJSONで（関数コンストラクターを介して）使用します。

私は従う傾向クロックフォードのアドバイスのためにeval()、そして完全にそれを避けます。それを必要とするように見える方法でさえもそうではありません。たとえば、setTimeout()ではevalではなく関数を渡すことができます。

setTimeout(function() {
  alert('hi');
}, 1000);

信頼できるソースであるとしても、JSONから返されたコードが文字化けしている可能性があるため、私はそれを使用していません。

evilはevilであるため、evalを使用しないことを推奨しているのを見ましたが、同じ人がFunctionとsetTimeoutを動的に使用しているため、内部で evalを使用しているのがわかりました。

ところで、サンドボックスが十分に明確でない場合（たとえば、コードインジェクションを許可するサイトで作業している場合）、evalは最後の問題です。セキュリティの基本的なルールがあることである、すべての入力が悪であるが、JavaScriptの場合にも、 JavaScriptであなたが任意の関数を上書きすることができますし、あなただけの、そう、あなたが本当のものを使用していることを確認することはできませんので、JavaScriptの自体は、悪の可能性悪意のあるコードがあなたの前に始まる場合、JavaScript組み込み関数を信頼することはできません：D

この投稿のエピローグは次のとおりです。

あなたがいる場合本当にそれを必要とする（時間のevalの80％がされないで必要）と、ちょうど使用evalをやって再何」は、あなたがしていることを確認（またはより良い機能を;））、閉鎖やOOPは、80/90％をカバー別の種類のロジックを使用してevalを置き換えることができる場合、残りは動的に生成されたコード（たとえば、インタープリターを作成している場合）であり、JSONの評価についてすでに述べたように（ここではCrockfordの安全な評価を使用できます;））

Evalは、コードのテンプレート化に使用されるコンパイルを補完します。テンプレート化とは、開発速度を向上させる便利なテンプレートコードを生成する簡略化されたテンプレートジェネレータを作成することを意味します。

開発者がEVALを使用しないフレームワークを作成しましたが、開発者は私たちのフレームワークを使用しているため、そのフレームワークはテンプレートを生成するためにEVALを使用する必要があります。

EVALのパフォーマンスは、次の方法を使用して向上させることができます。スクリプトを実行する代わりに、関数を返す必要があります。

var a = eval("3 + 5");

次のように構成する必要があります

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

fをキャッシュすると速度が向上します。

また、Chromeでは、このような機能のデバッグを非常に簡単に行うことができます。

セキュリティに関しては、evalを使用してもしなくてもかまいません。

1. まず、ブラウザはサンドボックスでスクリプト全体を呼び出します。
2. EVALで悪であるコードはすべて、ブラウザ自体で悪です。攻撃者または誰でも、DOMにスクリプトノードを簡単に挿入し、評価できる場合は何でもできます。EVALを使用しなくても違いはありません。
3. 有害なのは、ほとんどの場合サーバー側のセキュリティが低いことです。サーバーでのCookie検証が不十分であるか、ACLの実装が不十分であると、ほとんどの攻撃が発生します。
4. 最近のJavaの脆弱性などがJavaのネイティブコードにありました。JavaScriptはサンドボックスで実行するように設計されていますが、アプレットは脆弱性やその他多くの原因となる証明書などを使用してサンドボックスの外部で実行するように設計されています。
5. ブラウザを模倣するためのコードを書くことは難しくありません。必要なのは、お気に入りのユーザーエージェント文字列を使用してサーバーにHTTP要求を行うことだけです。いずれにしても、すべてのテストツールはブラウザを模擬します。攻撃者があなたを傷つけたい場合、EVALは最後の手段です。サーバー側のセキュリティに対処する方法は他にもたくさんあります。
6. ブラウザーDOMは、ユーザー名ではなく、ファイルへのアクセス権を持っていません。実際、evalがアクセス権を付与できるマシンには何もありません。

サーバー側のセキュリティが誰でもどこからでも攻撃できるほど強固であれば、EVALについて心配する必要はありません。前述したように、EVALが存在しない場合、攻撃者はブラウザのEVAL機能に関係なく、サーバーにハッキングするための多くのツールを持っています。

Evalは、事前に使用されていないものに基づいて複雑な文字列処理を行うテンプレートを生成する場合にのみ適しています。たとえば、私は好みます

"FirstName + ' ' + LastName"

とは対照的に

"LastName + ' ' + FirstName"

私の表示名として、これはデータベースから取得でき、ハードコーディングされていません。

Chrome（v28.0.1500.72）でデバッグするとき、クロージャーを生成するネストされた関数で使用されていない変数はクロージャーにバインドされていないことがわかりました。それはJavaScriptエンジンの最適化だと思います。

BUT：eval()クロージャを引き起こす関数内で使用される場合、外部関数のすべての変数は、たとえそれらがまったく使用されなくても、クロージャにバインドされます。それによってメモリリークが発生する可能性があるかどうかをテストする時間があれば、コメントを残してください。

これが私のテストコードです：

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

ここで指摘したいのは、eval（）は必ずしもネイティブeval()関数を参照する必要はないということです。それはすべて関数の名前に依存します。したがってeval()、エイリアスを使用して（たとえばvar noval = eval;、内部関数でnoval(expression);）ネイティブを呼び出すexpressionと、クロージャの一部であるはずの変数を参照するときに、の評価が失敗することがありますが、実際にはそうではありません。

マイクロソフトは、ブラウザーでeval（）が遅い理由をIEブログのIE + JavaScript Performance Recommendations Part 2：JavaScript Code Inefficienciesで説明しています。

ボトムライン

あなたが自分でコードを作成またはサニタイズした場合eval、それが悪になることはありません。

やや詳細

evalある邪悪されたクライアントから提出された入力を使用してサーバー上で実行されている場合は、開発者によって作成されていないか、された開発者によってサニタイズありません。

evalクライアントで作成された無害化されていない入力を使用しても、クライアントで実行している場合は問題ありません。

明らかに、コードが消費するものをある程度制御するために、常に入力を無害化する必要があります。

推論

クライアントは、開発者がコーディングしていない場合でも、必要な任意のコードを実行できます。これは、評価されたものだけでなく、それ自体へevalの呼びかけにも当てはまります。

eval（）を使用する必要がある唯一の例は、動的JSをその場で実行する必要がある場合です。私はあなたがサーバーから非同期でダウンロードするJSについて話している...

...そして10回のうち9回は、リファクタリングによって簡単に回避できます。

evalめったに正しい選択ではありません。スクリプトを連結してその場で実行することにより、達成する必要があることを達成できる多くのインスタンスがあるかもしれませんが、通常は、より強力で保守可能なテクニックを自由に使用できます。連想配列表記（obj["prop"]と同じですobj.prop） 、クロージャ、オブジェクト指向テクニック、関数テクニック-代わりにそれらを使用してください。

クライアントスクリプトに関する限り、セキュリティの問題は議論の余地があると思います。ブラウザに読み込まれるものはすべて操作の対象となるため、そのように扱う必要があります。ブラウザのURLバーなど、JavaScriptコードを実行したり、DOM内のオブジェクトを操作したりする方法がはるかに簡単な場合、eval（）ステートメントを使用してもリスクはありません。

javascript:alert("hello");

誰かが自分のDOMを操作したい場合、私は振り向かないと言います。あらゆる種類の攻撃を防ぐためのセキュリティは、常にサーバーアプリケーションの責任です。

実用的な観点からは、他の方法で実行できる状況でeval（）を使用するメリットはありません。ただし、evalを使用する必要がある特定のケースがあります。その場合、ページを爆破するリスクなしに確実に実行できます。

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>

サーバー側では、sql、influxdb、mongoなどの外部スクリプトを処理するときにevalが役立ちます。サービスを再デプロイせずに、実行時にカスタム検証を行うことができる場所。

たとえば、次のメタデータを持つ達成サービス

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

許可すると、

• jsonのリテラル文字列を介したオブジェクト/値の直接注入。テキストのテンプレート化に役立ちます

• コンパレーターとして使用できます。CMSでクエストまたはイベントを検証する方法をルール化するとします

これの欠点：

• 完全にテストされていない場合、コードのエラーが発生し、サービスの問題が解消される可能性があります。

• ハッカーがシステムにスクリプトを書くことができる場合、あなたはかなりめちゃくちゃです。

• スクリプトを検証する1つの方法は、スクリプトのハッシュを安全な場所に保管して、実行前にチェックできるようにすることです。

evalが正当化されるケースはほとんどないと思います。実際に正当化されているときに使用するよりも、正当化されていると考えて使用する可能性が高くなります。

セキュリティの問題は最もよく知られています。ただし、JavaScriptはJITコンパイルを使用しており、これはevalとの連携が不十分であることにも注意してください。Evalはコンパイラにとってブラックボックスのようなもので、パフォーマンスの最適化とスコープを安全かつ正確に適用するには、JavaScriptがコードを事前に（ある程度）予測できる必要があります。場合によっては、パフォーマンスへの影響がeval以外の他のコードに影響を与えることさえあります。

詳細を知りたい場合：https : //github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

eval関数に渡されるコードを完全に制御できる場合は、これを使用しても問題ありません。

可能であれば、テスト中のみ。また、eval（）は他の特殊なJSONなどのエバリュエーターよりもはるかに遅いことに注意してください。

コードのソースが自分または実際のユーザーからのものであることを確認できる限り、eval（）を使用しない理由はありません。彼はeval（）関数に送信されるものを操作できますが、Webサイトのソースコードを操作できるため、JavaScriptコード自体を変更できるため、セキュリティ上の問題ではありません。

だから... eval（）を使用しないのはいつですか？Eval（）は、第三者が変更する可能性がある場合にのみ使用してはなりません。クライアントとサーバー間の接続を傍受するようなものです（ただし、それが問題である場合はHTTPSを使用してください）。フォーラムのように他の人が書いたコードを解析するためにeval（）を使うべきではありません。

それが本当に必要な場合、評価は悪ではありません。しかし、私が偶然見つけたevalの使用の99.9％は必要ありません（setTimeoutのものは含みません）。

私にとって、悪はパフォーマンスでもセキュリティの問題でもありません（間接的には両方です）。evalのこのような不必要な使用はすべて、保守の地獄に追加されます。リファクタリングツールは破棄されます。コードの検索は難しいです。これらの評価の予期しない影響は軍団です。

JavaScriptのeval（）が悪ではないのはいつですか？

私はいつもevalを使わないようにしています。ほとんどの場合、よりクリーンで保守可能なソリューションを利用できます。JSON解析でも Eval は必要ありません。Eval はメンテナンスの地獄に追加されます。理由もなく、ダグラス・クロックフォードのよ​​うな巨匠たちに嫌われています。

しかし、私はそれが使用されるべき一例を見つけました：

式を渡す必要がある場合。

たとえば、一般的なgoogle.maps.ImageMapTypeオブジェクトを作成する関数がありますが、zoomとcoordパラメータからタイルURLを作成する方法をレシピに伝える必要があります。

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

使用例eval：インポート。

通常どのように行われるか。

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

しかしeval、少しのヘルパー関数の助けを借りて、よりよく見えるようになります：

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable （このバージョンは具象メンバーのインポートをサポートしていません）。

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}

Evalは悪ではなく、単に誤用されています。

あなたがそれに入るコードを作成したか、それを信頼できるなら、それは大丈夫です。人々はevalでユーザー入力がどのように重要でないかについて話し続けます。じゃあ〜

サーバーに送られるユーザー入力がある場合、クライアントに返され、そのコードはサニタイズされずにevalで使用されます。おめでとうございます。ユーザーデータを誰にでも送信できるようにpandoraのボックスを開きました。

evalがどこにあるかに応じて、多くのWebサイトがSPAを使用します。evalを使用すると、ユーザーがアプリケーションの内部に簡単にアクセスできるようになります。今度は、そのevalにテープで記録してデータを再び盗む偽のブラウザ拡張を作成できます。

評価を使用するあなたのポイントが何であるかを理解するだけです。そのようなことをするためのメソッドを作成したり、オブジェクトを使用したりするだけの場合、コードの生成は実際には理想的ではありません。

今度はevalを使用する良い例です。サーバーは、作成したswaggerファイルを読み取っています。URLパラメータの多くは、という形式で作成されます{myParam}。したがって、エンドポイントが多いため、複雑な置換を行わなくても、URLを読み取ってテンプレート文字列に変換したいとします。だからあなたはこのようなことをするかもしれません。これは非常に単純な例です。

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

コード生成。私は最近、仮想domとハンドルバー間のギャップを埋めるハイパーバーと呼ばれるライブラリを書きました。これは、ハンドルバーテンプレートを解析し、それをハイパースクリプトに変換することによって行われます。ハイパースクリプトは最初に文字列として生成され、それを返す前に、実行可能コードに変換します。私はこの特定の状況で悪の正反対を見つけました。eval()eval()

基本的に

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

これに

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

このeval()ような状況でも、生成された文字列を1回解釈し、実行可能ファイルの出力を何度も再利用するだけでよいため、パフォーマンスは問題になりません。

ここで興味があれば、コード生成がどのように行われたかを確認できます。

私の考えでは、evalはクライアント側のWebアプリケーションにとって非常に強力な機能であり、安全です... JavaScriptほど安全ではありませんが、そうではありません。:-)現在、Firebugなどのツールを使用すると、任意のJavaScriptアプリケーションを攻撃できるため、セキュリティの問題は本質的にサーバー側の問題です。

Evalは、マクロがない場合のコード生成に役立ちます。

（愚かな）例として、Brainfuckコンパイラーを作成している場合は、一連の命令を文字列として実行する関数を作成し、それを評価して関数を返す必要があります。

解析関数（jQuery.parseJSONなど）を使用してJSON構造を解析する場合、JSONファイルの完全な構造が期待されます（各プロパティ名は二重引用符で囲まれています）。ただし、JavaScriptの方が柔軟性があります。したがって、eval（）を使用してそれを回避できます。