15

多くの開発者は、JavaScript のeval()メソッドは避けるべきだと考えています。このアイデアは、デザインの観点から理にかなっています。よりシンプルで優れたオプションが利用可能な場合、これは醜い回避策としてよく使用されます。

ただし、セキュリティの脆弱性に関する懸念は理解できません。確かに、実行eval()すると、実行可能な JavaScript コードをハッカーが実行できるようになります。

しかし、とにかく彼らはこれを行うことはできませんか? 少なくとも Chrome では、開発者ツールを使用してエンドユーザーが独自の JavaScript を実行できます。eval()開発者ツールよりも危険なのは?

4

2 に答える 2

21

B-Con が述べたように、攻撃者はコンピュータの前に座っている人ではないeval()ため、現在のユーザーのセッションを何らかの方法で悪用するために、悪意のあるコードをサイトに渡す手段として、スクリプトに既に含まれているものを使用している可能性があります (たとえば、次のユーザー悪意のあるリンク)。

サニタイズされていない値に対して実行されると危険であり、 DOM ベースの XSS脆弱性eval()につながる可能性があります。

たとえば、HTML で次のコードを検討してください (やや不自然ですが、問題を示していることを願っています)。

<script>

eval('alert("Your query string was ' + unescape(document.location.search) + '");');

</script>

クエリ文字列が の?foo場合、次のようなアラート ダイアログが表示されます。Your query string was ?foo

しかし、このコードでユーザーができることは、ユーザーを自分のサイトから などの URL にリダイレクトすることですhttp://www.example.com/page.htm?hello%22);alert(document.cookie+%22。ここで、www.example.com はあなたの Web サイトです。

これにより、によって実行されるコードが変更されeval()ます

alert("Your query string was hello");
alert(document.cookie+"");

（わかりやすくするために私が追加した新しい行）。現在、これは現在の Cookie 値を表示するよりも悪意のあることを行っている可能性があります。必要なコードは、攻撃者のリンクによってエンコードされた形式でクエリ文字列に渡されるだけだからです。たとえば、リソース要求で攻撃者のドメインに Cookie を送信し、認証セッションをハイジャックできるようにする可能性があります。

eval()これは、ここに示すクエリ文字列だけでなく、サニタイズされておらず、 で直接実行されるユーザー/外部入力からのすべての値に適用されます。

于 2013-08-13T11:35:39.763 に答える
6

攻撃者は、ユーザーのブラウザーの開発者ツールにアクセスできません。攻撃者は、コンピューターの前に座っているユーザーではない可能性があります。

危険なのeval()は、攻撃者が最終的eval()に他の方法で実行されるデータを操作できる可能性があることです。'd 文字列が HTTP 接続からのものである場合eval()、攻撃者は MITM 攻撃を実行して文字列を変更する可能性があります。文字列が外部ストレージから取得された場合、攻撃者はそのストレージの場所にあるデータを操作した可能性があります。等。

于 2013-08-12T14:30:18.580 に答える