自分の制御不能なJavaScriptコードが自分のページで実行される危険性は何ですか？
私のウェブサイトのページは、サードパーティのCDN（分析など）からのJavaScriptコードを参照しています。だから私はそこにあるコードを制御しません-サードパーティはいつでもこれらのスクリプトを変更し、何かbadをこれらのスクリプトに導入する可能性があります-偶然かもしれないし、意図的にかもしれない。これらのスクリプトが変更されると、ユーザーはブラウザーで新しいコードの受信と実行を開始します。
この制御されていないコードによってどのようなリスクが発生しますか？起こり得る最悪のことは何ですか？リスクの管理を開始するにはどうすればよいですか？
危険
最悪のシナリオでは、ユーザーがWebサイトに完全にアクセスできなくなったり、アカウントの削除を要求したり、お金を使ったりするなど、特定のアクションを実行したり、機密データを盗んだりする可能性があります。
防止
できません。 Webサイトで他の人のJavaScriptを実行すると、そのサードパーティよりも安全でなくなります。自分でホストする必要があります。
ただし、ターゲットに近づくことができます。
- コンテンツセキュリティポリシー の可能性があります。ヘッダー
Content-Security-Policyをscript-src 'self' www.google-analytics.com;に設定する例では、独自のドメインまたはwww.google-analytics.com以外のドメインから提供されるスクリプトの実行を防止します。そうすれば、誰かが独自のインラインJavaScriptコードをWebサイトに追加できるクロスサイトスクリプティングの脆弱性（XSS）を見つけた場合、実行されません。 - 他の本当にクールなものは、いわゆる Subresource Integrity です。これは基本的に、
integrityタグに指定したscriptパラメータに実行する予定のJSのハッシュ合計を追加しています。
<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"/>
これらのハッシュは、オンライン https://www.srihash.org/ またはコマンドで生成できます。
openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A
もちろん、これにはマイナス面もあります。分析プロバイダーはスクリプトを変更する場合があり、それらを実行し続けるにはintegrityパラメーターを変更する必要があります。また、これはかなり新しい機能（Chrome 45.0以降、Firefox 43以降、Opera 32以降、IE、Edge、またはSafariのサポートなし））なので、クライアントのセキュリティを独自のソフトウェアに置くことができます。
OWASPの サードパーティJavascript管理チートシート も参照してください。
起こり得る最悪のことは何ですか？
サードパーティは、JavaScriptで実行できること、または攻撃者がXSSで実行できるすべてのことを実行できます。
これには、Cookieの盗用、JavaScriptキーロガーの挿入、CSRF保護の回避、したがって実行可能なすべての要求の実行（新しい管理ユーザーの追加など）、またはWebページのコンテンツの変更（広告の挿入やフィッシング攻撃など）が含まれます。
リスクへの対応を始めるにはどうすればよいですか？
サードパーティの意図やセキュリティを信頼しない場合、適切な解決策は、スクリプトを自分でホストすることです（スクリプトが自分のやりたいことだけを実行することを確認した後）。
これを実行したくない場合は、サブリソースの整合性を追加して、リスクをある程度軽減できます。
スクリプトのハッシュをインクルードに追加すると、 modern browsers がハッシュをインクルードされたファイルのハッシュと比較します。一致しない場合、コードは実行されません：<script src="https://example.com/script.js" integrity="[hash]" crossorigin="anonymous"></script>。これにより、スクリプトが変更されないようにすることができます。もちろん、変更された場合は、スクリプトを再確認してハッシュを変更する必要があります。そうしないと、Webサイトが壊れてしまいます。
この制御されていないコードによってどのようなリスクが発生しますか？起こり得る最悪のことは何ですか？
一般に、攻撃者は認証方法が保護しようとしているものすべてにアクセスできます。
最悪の場合、コードがサイト用にカスタム設計されていると想定します。ユーザーが実行するアクションは、セキュリティ資格情報を入力するように促される可能性があり、攻撃者がログアウトした後もそのユーザーのアカウントにアクセスできるようにします。銀行口座、ビットコインの財布、または資産へのアクセスを制御するその他のサイトの場合、攻撃者は元に戻せない高価値のアクションにアクセスできます。現時点では価値はないが、アカウントにアクセスするための資格情報を取得した場合、アカウントに十分な価値があり、価値があるようになるまで待つことができます。
リスクへの対応を始めるにはどうすればよいですか？
良い例：自分でホストするスクリプトにコンテンツセキュリティポリシーとサブリソース整合性を設定します。これらの詳細については、@ Przemekの回答を参照してください。これを言う必要があるかどうかはわかりませんが、JavaScriptはすべてHTTP経由で提供する必要があります。これにより、少なくともこれらのリソースのMITMのコストが上昇します。
より良い：コードを自分でホストします。ただし、定期的に更新することを忘れないでください。これらのベンダーは、独自のセキュリティ修正をリリースしています。取り残されないでください。
ベスト：すべてのソースコードを確認します。ほとんどの場合、自分で読むことができるJSの非縮小バージョンを見つけて（最終的には差分を表示する）、それを縮小して他のサイトのJSとバンドルすることができます。これは明らかに高コストです。サイトのニーズに合わせて適切に重み付けしてください。
上記のすべてを検討する価値がありますが、公平を期すために、認められている開発慣行と、前述の最も深刻なケースから保護する最新のブラウザーには組み込みの保護機能があります。
また、サードパーティのコードがWebページと同じコンテキストで実行できる（つまり、同じブラウザDOMを共有する）方法が3つあることにも注意してください。1）ページとともにインクルードしてレンダリングするJS。 Google Analytics、または2）ユーザーが制御するブックマークレット（SpritzletやPinterestなど）、および3）ブラウザ拡張機能またはツールバー。後者の2つはほとんど完全に制御できません。 1つ目は、ある程度監査できるものです。
確認する必要がある最も断然重要なことは、クライアント（ブラウザ、ボット、マルウェア）にサービスを提供して応答するWeb serversを制御することです。 XSS、CSRF、SQLインジェクション、およびその他の複数の攻撃ベクトルは、サーバー側で制御できます。サーバー側でCORSを明示的に許可する必要がありますが、許可する場合は、何をしているのかを確認し、特に警戒してください。これはすべてが簡単または明白であるとは限りませんが、JSまたは他の方法を介して脆弱性が侵害されているかどうかにはまったく依存しません。
Webサーバーを保護し、呼び出し可能なエンドポイントをロックしたとすると、問題の残りの部分は別のクラスに分類されます。 JS（およびplugins/extensions/toolbars/bookmarklets）は、キーストロークロガー、実際には他の場所にデータを送信する無害に見える要素の挿入など、さまざまな悪いことを実行できます。これらはすべてブラウザによって実行されます。
サードパーティに代わってJSを提供している場合は、ソースを信頼して検証するように注意する必要があります。 Google Analyticsスニペットはおそらく安全です。サードパーティの広告配信ウィジェットは、もっと注意深く調べる価値があるかもしれません。すべての場合において、これらの背後にあるコードを検査できます。ブラウザーがそれを実行できる場合、JSコードを確認して、次のことを決定できます。これは、サイトに必要なものですか？
JavaScriptは強力なツールです。しかし、結局のところ、JSはブラウザが実行するソフトウェアであるため、安全を確保するために、ブラウザとそれを実行するオペレーティングシステムに多くの信頼を置いています。 JSは、サーバーを侵害したり、サーバーに設計されていない機能を実行させたりする特定の魔法の能力を持つソフトウェアではありません。
JSがユーザーのコンピューター上で任意にコードを実行できるようにするサイトでできることはほとんどありません-ブラウザーやOSなどに最新のアップデートを適用する必要があるのはユーザーです。古いバージョンを検出し、警告を投稿してニースにすることができます男、しかしそれはそれについてです。
サーバーを保護し、アップデートをインストールし、コードが安全であることを確認し、不明なサードパーティからJSを提供しないようにします。次に、サイトがGoogleウェブマスターツールに登録されていることを確認します。これにより、サイトが多くの場合ハッキングされているかどうかが通知されます。また、余裕がある場合は、サイトの脆弱性をスキャンするサービスを利用できます。
起こり得る最悪のことは何ですか？
技術用語は任意のコードの実行です。このコンテキストでは、「任意」は「JavaScript」でコーディングできるすべてのもののように、「任意」を意味します。最終的にはサイトで実行されます。」
JavaScriptを使用してフォームフィールドから値を読み取ることはできますか？はい。 JavaScriptを使用してURLから何かをロードすることは可能ですか？はい。次に、任意のコード実行とは、誰かがユーザーのログイン時にユーザーのユーザー名とパスワードを読み取り、GETリクエストのパラメーターとしてエンコードされた独自のサーバーに送信することを意味します。 （これにより、ユーザーのログインデータのHTTPS暗号化を適切に実行できます。）
JavaScriptを使用してページ上のデータを読み取ることはできますか？はい。次に、任意のコードが実行されると、誰かがユーザーのプライベートプロファイルデータを含むページにアクセスしたときに、そのデータが読み取られる可能性があります。 （そして、HTTPリクエストを使用して、それを攻撃者のサーバーに報告します。）
...等々。任意のコード実行の脆弱性は、サイバーセキュリティの観点から考えられる最悪の事態と考えられています。これを悪用すると、文字通り、起こり得るあらゆる悪いことを実行できるからです。あなたのシステム。