大手金融会社の Web サイトで作業している私たちは、「セキュリティ上の懸念」から、サイト全体で使用されている jQuery ライブラリの CDN ホスト バージョンの使用をためらう傾向があります。
これらの懸念は、Google または Microsoft のサーバーでコードが危険にさらされるリスク、これらの CDN ネットワークが利用できなくなることによる評判のリスク (それによって機能をレンダリングすること) による潜在的な物理的なセキュリティの脅威に関連していると思います (ただし、完全に説明したことはありません)。これらの状況から生じる可能性のあるその他の固有のリスク。
私の質問は、これらの種類のセキュリティ上の懸念はどの程度有効であり、CDN がホストするネットワークで見つかったセキュリティ リスクを軽減するために何ができるでしょうか?
JavaScript インクルードとしてのみ使用し、JavaScript はクライアント側のみであるため、DOM を介して XHTML としてレンダリングされるあらゆるものにアクセスできる可能性があります。これは、CDN がハッキングされ、含めた JavaScript が悪意を持って変更された場合に基づいています。クロスドメインで使用される JavaScript に関する情報については、Google の JavaScript API が AJAX のクロスドメイン セキュリティをどのように回避するかを参照してください。
他の人が言ったように、利点がほとんどないことを考えると、リスクを冒す価値はありません. 一般的に、JavaScript ライブラリは小さすぎて、サーバーのスペース、帯域幅、アクセス速度などを節約することはできません。
CDNネットワークが利用できなくなることに関して：それは非常にありそうになく、可用性のパーセンテージはあなた自身のネットワークよりも高くなる可能性があります。自分でホスティングすることで、少なくともシステムが誤動作しているときにのみダウンタイムが発生し、問題の原因となるネットワーク障害の断面積が最小になると主張できます。
セキュリティに関して：データが危険にさらされたり、送信チャネルが傍受されたり、XSSおよびCSRF攻撃を介して悪意のあるコードが代わりに送信されたりする可能性があります。私の意見では、これもまた非常に低い可能性があります。
警告メッセージと一致しない証明書に関するCookieの懸念と安全な接続の懸念（httpではなくhttps経由）もあります（http://idunno.org/archive/2009/09/16/quick-thoughts-on-を参照） the-microsoft-ajax-cdn.aspx）。MicrosoftはSSLをサポートしていますが、YahooとGoogleについてはよくわかりません（サポートする必要があります）。GoogleはCookieを使用して追跡しませんが、IPがCDNネットワークに到達していることを確認し、必要に応じて追跡に使用できます。
CDNの値は、ユーザーがCDNを使用して他のサイトにアクセスした場合、スクリプトのローカルキャッシュを介してある程度の速度になります。しかし、主要な機関にとっては、その必要性はわかりません。
ユーザーがログインしたら、絶対に必要な場合を除いて、あらゆる種類のクライアントスクリプトを避けようとします。オンライン金融サービスに関するウェブ作業に推奨する推奨事項は次のとおりです。
1) 同じドメインから HTTPS 経由ですべてのアセットをユーザーに送信します。速度が遅く、帯域幅のコストが最も高くなりますが、すべてのアセットを直接操作から制御できるため、より安全です。すべての資産とは、実際には画像を含むすべての資産を意味します。テキスト コンテンツを含む画像を操作すると、フィッシングの試みに先立って誤った指示を送信するために使用される可能性があるからです。この点で、CDN を使用してアセットを保存することはありません。それはあなたが所有する場所ではないため、保存されたデータの改ざんを監視する制御が少ないためです。
2) XMLHttpRequest オブジェクトで AJAX などを使用しないでください。非同期通信のポイントは、ページのリロード以外のポイント間で情報をビーコンすることです。これは使いやすさには優れていますが、セキュリティを完全に無効にします。クライアント側で実行されるため、侵害されたコードは、ユーザー側で情報が復号化された後、ユーザーからの情報を信頼できない第三者にビーコンすることにより、正当な SSL 暗号化を無効にするためにも使用できます。購入、PII、または財務データを扱うときは、ユーザーからの情報トランザクションごとにページのリロードまたは新しいページが強制的に実行されることを常に確認してください。
3) いかなる種類のクライアント側スクリプトも使用しないでください。その手段は、ActiveX、Flash、さらには Acrobat をまったく使用しません。報告されたすべてのセキュリティ脆弱性の 95% はクライアント側のスクリプトに起因しており、それらの攻撃の 70% は処理ソフトウェアのメモリ破損を標的にしています。通常、JavaScript はバッファ オーバーフローで知られているわけではありませんが、DOM のみを操作するために JavaScript をできるだけ使用しないことをお勧めします。
4) JavaScript の関数またはメソッドで無名関数を引数として渡さないでください。これは一般的に発生するものではありませんが、特定の組み込みメソッドの場合、JavaScript インタープリターを介して処理ソフトウェアに穴が開く可能性があります。これは、バッファ オーバーフローを引き起こすために必要なコードを挿入するための攻撃ベクトルになる可能性があります。
5) onsubmit イベントを使用して、フォーム データの送信にスクリプトの実行を関連付けないでください。実行コードに違反したり、追加の悪意のあるコードを追加したりすると、フォーム データを信頼できるソースに送信する前に、フォーム データを信頼できない第三者に匿名でビーコンする XMLHttpRequest 関数を含めるポイントが作成される可能性があります。属性は HTTPS です。
6) 有効な XHTML、CSS、およびテキストをユーザー エクスペリエンスのほぼすべての可能な側面に固執し、HTTPS のみを使用して通信する限り、ほとんど問題ありません。
銀行や教育機関は既知の攻撃の 40% を受けていることを心に留めておく必要があります。2008 年の 1 回の攻撃の平均コストは 1,130 万ドルでした。セキュリティの完全な深さを考慮していなかったために、銀行がそれらの損害についてあなたを攻撃する可能性がある場合、どのように対応しますか? それに応じて計画を立て、作業が可能な限りロックダウンされるようにします。
無料のCDNでホストされているバージョンについては、利用規約を確認する必要があります。しかし、「大手金融会社」にとっては、おそらく十分ではないでしょう。
CDNを使用したい場合は、そのうちの1つと契約を結び、独自の「CDNホスト」バージョンを使用するのはどうでしょうか。CDN帯域幅は驚くほど手頃な価格です。
彼らのサーバーのセキュリティはあなたのサーバーのセキュリティよりもはるかに優れていると思いますが、彼らのサーバーへの攻撃の量はあなたのサーバーへの攻撃の量よりもはるかに多いです。
すべての画像やスタイルなどにCDNを使用しない場合は、CDNをまったく使用しないでください。これは単一のファイルなので、あなたとあなたのサイトのユーザーに大きな違いはありません。