web-dev-qa-db-ja.com

JavaScriptのeval（）メソッドを活用する

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

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

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

javascriptsecurityevalclient-sidecode-injection
11
Jared Nielsen

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

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

例えばHTML内の次のコードを検討してください（かなり工夫されていますが、私が望む問題を示しています）

_<script>

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

</script>
_

これで、クエリ文字列が_?foo_の場合、次のことを示すアラートダイアログが表示されます。_Your query string was ?foo_

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

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

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

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

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

13
SilverlightFox

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

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

4
B-Con