コメント：序文：HTML5が表示された後、ネットワークセキュリティはより広範な注目を集めています。ネットワークセキュリティに対してWebはどのような改善を行っていますか？ますます危険なサイバー詐欺と攻撃にどのように直面するのでしょうか？次の記事では、この問題に対するW3Cの最新の解決策について説明しています。将来機会があれば、XSS、P3P、相同政策、CORS（クロスドメインリソース共有）およびCSPでHTML5コンテンツを実施します。
World Wide Webのセキュリティポリシーは、相同政リに根ざしています。たとえば、コードはデータのみにアクセスできますが、アクセス権限はありません。各ソースはネットワークの残りの部分から分離されており、開発者向けの安全なサンドボックスを作成します。これは理論的には完璧ですが、今では攻撃者はシステムを破壊する賢い方法を見つけました。これは、XSSクロスサイトスクリプト攻撃であり、偽のコンテンツを介して相同ポリシーをバイパスし、クリックをしつけます。これは大きな問題です。攻撃者がコードを正常に注入すると、かなりの量のユーザーデータが漏れます。
次に、このリスクを軽減するための真新しく効果的なセキュリティ防衛戦略を導入します。これは、Contentsecurityポリシー（CSP）です。
ソースホワイトリスト
XSS攻撃のコアは、ブラウザがスクリプトがサードパーティによって挿入されているか、実際にアプリケーションの一部であるかを知ることができないことです。たとえば、Google +1ボタンはhttps://apis.google.com/js/plusone.jsからコードを読み込んで実行しますが、ブラウザーの写真から、コードが実際にapis.google.comからであるか、apis.evil.example.comからであるかを知ることはできません。ブラウザは、ソースに関係なく、コードのページリクエストをダウンロードおよび実行します。
CSPは、Content-Security-PolicyHTTPヘッダーを定義して、信頼できるソースのホワイトリストを作成できるようにし、ブラウザはサーバーが提供するすべてを盲目的に信頼するのではなく、それらのソースからのみリソースを実行およびレンダリングするようにします。攻撃者がスクリプトを注入する脆弱性を見つけても、ソースがホワイトリストに含まれていないため、実行されません。
上記のGoogle +1ボタンは例です。Apis.google.comが有効なコードを提供していると考えているため、自分自身と同様に、ブラウザが以下の2つのソースのいずれかからスクリプトを実行できるポリシーを定義できると考えています。
Content-Security-Policy：Script-src 'self' https://apis.google.com
とても簡単ではありませんか？ Script-SRCは、指定されたページのスクリプト関連の権限を制御できます。このようにして、ブラウザはこのページからのスクリプト自体からのみをダウンロードして実行します。
このポリシーを定義すると、ブラウザは注入されたコードを検出するとエラーがスローされます（ブラウザが何であるかに注意してください）。
コンテンツセキュリティポリシーは、すべての共通リソースに適用されます
スクリプトリソースは最も明白なセキュリティリスクですが、CSPは、ページが次のタイプなど、さまざまなタイプのリソースのロードを制御できるようにする豊富な一連の命令も提供します。
Content-SRC：接続の種類を制限します（XHR、WebSocket、EventSourceなど）
Font-SRC：ネットワークフォントのソースを制御します。たとえば、font-src https://themes.googleusercontent.comを介してGoogleのWebフォントを使用できます。
Frame-SRC：埋め込むことができるフレームのソースをリストします。たとえば、frame-src https://youtube.comでは、YouTubeに埋め込まれたビデオのみを許可しています。 。
IMG-SRC：ロード可能な画像のソースを定義します。
Media-SRC：ビデオとオーディオのソースを制限します。
Object-SRC：フラッシュのソースやその他のプラグインを制限します。
Style-SRC：Script-SRCと同様に、CSSファイルでのみ動作します。
デフォルトでは、すべての設定が制限なしにオンになっています。複数の命令をセミコロンで分離できますが、スクリプトsrc https：//host1.com; script-src https://host2.comと同様に、2番目の命令は無視されます。それを書く正しい方法は、script-src https://host1.com https://host2.comです。
たとえば、コンテンツ配信ネットワーク（CDN、https：//cdn.example.netなど）からすべてのリソースをロードする必要があるアプリケーションがあり、フレームとプラグインなしのコンテンツが必要であることを知っている場合、戦略は次のようになるかもしれません。
Content-Security-Policy：デフォルトsrc https://cdn.example.net; frame-src 'none'; object-src 'none'
詳細
私の例で使用したHTTPヘッダーはContent-Security-Policyですが、最新のブラウザーはすでにプレフィックスを介してサポートを提供しています。FirefoxはX-Content-Security-Policyを使用します。WebKitはX-Webkit-CSPを使用します。将来的には、徐々に統一された基準に移行します。
戦略は、異なるページごとに設定できます。これにより、多くの柔軟性が提供されます。あなたのサイト上のいくつかのページにはGoogle +1ボタンがあるかもしれませんが、他のページはそうではありません。
各命令のソースリストは非常に柔軟です。パターン（データ：https :)、または範囲のホスト名（example.com、任意のソース、任意のモード、ホストのポートに一致する）を指定するか、完全なURI（https://example.com:443、特にhttpsプロトコル、example.comドメイン名、ポート443）を指定できます。
ソースリストで4つのキーワードを使用することもできます。
なし：あなたは何かを不一致にすることを期待するかもしれません
自己：現在のソースと同じですが、サブドメインは含まれていません
Unsafe-Inline：インラインJavaScriptとCSSを許可します
Unsafe-Eval：評価などのJSにテキストを許可するメカニズム
これらのキーワードを引用する必要があることに注意してください。
サンドボックス
ここで議論する価値のある別の指示があります：Sandbox。それは他の指示とやや矛盾しています。それは、ページがロードできるリソースではなく、主にページで取られた動作を制御します。このプロパティが設定されている場合、ページはサンドボックスプロパティセットを備えたフレームのように動作します。これには、フォームの提出などの防止など、ページに幅広い影響があります。これは、この記事の範囲を少し超えていますが、HTML5仕様のSandboxロゴ設定セクションで詳細を見つけることができます。
有害なインラインコード
CSPはソースホワイトリストに基づいていますが、XSS攻撃の最大のソースであるインラインスクリプトインジェクションを解決しません。攻撃者が有害なコードを含むスクリプトタグ（<script> sendmydatatoevildotcom（）; </script>）を挿入できる場合、ブラウザにはこのタグを区別するための優れたメカニズムがありません。 CSPは、インラインスクリプトを完全に禁止することによってのみこの問題を解決できます。
この禁止には、スクリプトに埋め込まれたスクリプトタグだけでなく、インラインイベントハンドラーとJavascrpt：URLも含まれます。スクリプトタグの内容を外部ファイルに配置し、javaScriptを置き換える必要があります。たとえば、次のフォームを置くことができます。
<スクリプト>
関数doamazingthings（）{
アラート（ 'あなたはすごい！'）;
}
</script>
<ボタン>私はすごいですか？</button>
次のフォームに書き換えます。
<！ - amazing.html->
<スクリプトsrc = 'amazing.js'> </script>
<ボタン>私はすごいですか？</button>
// Amazing.js
関数doamazingthings（）{
アラート（ 'あなたはすごい！'）;
}
document.addeventlistener（ 'domcontentready'、function（）{
document.getElementById（ 'Amazing'）
.addeventlistener（ 'click'、doamazingthings）;
}）;
CSPを使用するかどうかに関係なく、上記のコードには実際に大きな利点があります。インラインJavaScriptは構造と動作を完全に混合します。そうしないでください。さらに、アウトリーチリソースはブラウザでのキャッシュが簡単で、開発者が理解しやすく、コンパイルして圧縮しやすいです。アウトリーチコードを使用すると、より良いコードを書きます。
インラインスタイルを同じ方法で処理する必要があります。スタイル属性とスタイルタグの両方を外部スタイルシートに抽出する必要があります。これにより、あらゆる種類の魔法のデータの漏れを防ぐことができます。
インラインスクリプトとスタイルが必要な場合は、スクリプトSRCまたはスタイル-SRC属性の「安全でないインライン値」を設定できます。しかし、これをしないでください。インラインスクリプトを禁止することは、CSPが提供する最大のセキュリティ保証です。同時に、インラインスタイルを禁止することで、アプリケーションをより安全で堅牢にすることができます。トレードオフですが、それだけの価値があります。
評価します
攻撃者がスクリプトを直接挿入できない場合でも、挿入されたテキストを実行可能なスクリプトに変換し、それを実行するようにアプリケーションを誘導する場合があります。 eval（）、newFunction（）、setimeout（[string]、...）、およびsetinterval（[string]、...）はすべて、そのような危険なキャリアになる可能性があります。このリスクをターゲットにするCSPの戦略は、これらのベクトルを完全にブロックすることです。
これは、アプリを構築する方法にいくつかの意味を持っています。
jsonは、json.parseを組み込んで、評価に依存せずに解析します。 IE8の後のブラウザは、ローカルJSONオペレーションをサポートしていますが、これは完全に安全です。
文字列の代わりにインライン関数によってSetimeOutとSetIntervalのコールメソッドを書き換えます。例えば：
setimeout（document.queryselector（ 'a'）。style.display= 'none';、10）;
次のように書き直すことができます
setimeout（function（）{document.queryselector（ 'a'）。style.display= 'none';}、10）;
実行時にインラインテンプレートを避けます。多くのテンプレートライブラリは、新しい関数（）を使用してテンプレートの生成を高速化します。これは動的なプログラムに最適ですが、悪意のあるテキストにとっては危険です。
報告
CSPは、サーバー側の信頼されていないリソースをブロックできます。これはユーザーにとって非常に便利ですが、さまざまな通知をサーバーに送信することは非常に便利です。この目的のために、Report-URIディレクティブを介してJSON形式のインターセプトレポートをアドレスに送信するようブラウザに指示することができます。
Content-Security-Policy：default-src 'self'; ...; Report-uri /my_amazing_csp_report_parser;
レポートは次のようになります：
{
csp-report：{
document-uri：、
リファラー：、
blocked-uri：
暴力的指導：スクリプト-SRC '自己' https://apis.google.com、
Original-Policy：script-src 'self' https://apis.google.com; Report-uri
}
}
その中に含まれる情報は、発生するドキュメントRURI、ページリファラー、ページポリシーに違反するリソース、違反した指令、およびすべてのページコンテンツの元のポリシーなど、ブロッキングの状況を特定するのに役立ちます。
現実的な使用
CSPは現在、Chrome 16+およびFirefox 4+ブラウザーで利用可能になり、IE10で限られたサポートを受けることが期待されています。 Safariはまだサポートされていませんが、WebKit Nightly Buildが利用可能であるため、以下の反復でSafariがサポートされることが予想されます。
以下の一般的に使用されているユースケースを見てみましょう。
実際のケース1：ソーシャルメディアウィジェット
Google +1ボタンには、https：//apis.google.comのスクリプトと、https://plusone.google.comから埋め込まれたiframesが含まれています。あなたのポリシーは、Google+1ボタンを使用するためにこれらのソースを含める必要があります。最も簡単な戦略は、スクリプトsrc https://apis.google.comです。 Frame-src https://plusone.google.com。また、Googleが提供するJSフラグメントが外部JSファイルに保存されていることを確認する必要があります。
Facebookのようなボタンには多くの実装ソリューションがあります。 IFRAMEバージョンは、サイトの他の部分から十分に隔離されたままにしておくことをお勧めします。これには、Frame-SRC https://facebook.comディレクティブの使用が必要です。デフォルトでは、Facebookが提供するIFRAMEコードは、Reternal Path //facebook.comを使用していることに注意してください。このコードをhttps://facebook.comに変更してください。 HTTPが使用しない必要はありません。
Twitterのツイートボタンは、両方ともhttps://platform.twitter.comからのスクリプトとフレームに依存します（Twitterはデフォルトで相対的なURLを提供します。コピーするときにコピーを編集してhttpsとして指定してください）。
他のプラットフォームには同様の状況があり、同様に解決できます。デフォルトSRCをなしに設定し、コンソールを検討して、ウィジェットが適切に機能することを確認するために使用する必要があるリソースを確認することをお勧めします。
複数のウィジェットを使用することは非常に簡単です。すべてのポリシー指令をマージし、同じ指令の設定を一緒に配置することを忘れないでください。上記の3つのウィジェットを使用したい場合、戦略は次のようになります。
Script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com
実際のケース2：防衛
銀行のウェブサイトにアクセスし、必要なリソースのみがロードされていることを確認したいとします。この場合、デフォルトの許可を設定して、すべてをブロックし（デフォルトSRC 'none'）、ポリシーをゼロから構築します。
たとえば、銀行のWebサイトでは、https：//cdn.mybank.netのCDNから画像、スタイル、スクリプトをロードし、https：//api.mybank.com/を介してXHRを介して接続する必要があります。また、フレームを使用する必要がありますが、フレームはすべて3歳以外のローカルページからのものです。ウェブサイトにフラッシュ、フォント、その他のコンテンツはありません。この場合、最も厳しいCSPヘッダーを送信できます。
Content-Security-Policy：default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com;フレーム-SRC「自己」
実際のケース3：SSLのみを使用します
ウェディングリングフォーラム管理者は、すべてのリソースを安全な方法でロードすることを望んでいますが、実際にはあまり多くのコードを書きたくありません。多数のサードパーティフォーラムインラインスクリプトとスタイルを書き換えることは、彼の能力を超えています。したがって、次の戦略は非常に便利です。
Content-Security-Policy：default-src https：; Script-src https： 'Unsafe-inline'; Style-SRCHTTPS：「安全でないインライン」
デフォルトSRCはHTTPSを指定していますが、スクリプトとスタイルは自動的に継承されません。各ディレクティブは、デフォルトのリソースタイプを完全にオーバーライドします。
未来
W3CのWebアプリケーションセキュリティワーキンググループは、コンテンツセキュリティポリシーの仕様の詳細を開発しています。バージョン1.0は、この記事で説明されているものに非常に近い最終改訂段階に入ります。 Public-Webappsec@ Email Groupはバージョン1.1について議論しており、ブラウザーメーカーもCSPの実装を統合および改善するために懸命に取り組んでいます。
CSP 1.1には、アートボードに別々にリストする価値がある興味深いものがいくつかあります。
メタタグを介してポリシーを追加する：CSPを設定する優先方法はHTTPヘッダーですが、これは非常に便利ですが、タグやスクリプトを介してより直接的なものになりますが、まだ確定していません。 WebKitはメタ要素を介して許可設定の機能を実装しているため、Chromeで次の設定を試すことができます。<Metahttp-equiv = x-Webkit-CSP Content = [Policy Goes dere]>ドキュメントヘッダーに追加できます。
実行時にスクリプトを介してポリシーを追加することもできます。
DOM API：この機能がCSPの次の反復に追加された場合、JavaScriptを使用してページの現在のセキュリティポリシーを照会し、さまざまな状況に従って調整できます。たとえば、eval（）が利用可能な場合、コードの実装がわずかに異なる場合があります。これは、JSフレームワークの著者にとって非常に便利です。また、API仕様はまだ非常に不確実です。ドラフト仕様のスクリプトインターフェイスセクションに最新のイテレーションを見つけることができます。
新しいディレクティブ：スクリプトノンスを含む多くの新しいディレクティブが議論されています。インラインスクリプトは、明示的に指定されたスクリプト要素が使用されている場合にのみ使用できます。プラグインタイプ：これにより、プラグインの種類が制限されます。フォームアクション：フォームを特定のソースのみに提出することを許可します。
これらの将来の機能についての議論に興味がある場合は、メーリングリストのアーカイブを読んだり、メーリングリストに追加したりできます。
この記事は以下から翻訳されています。
抜粋：江沢のブログから