コンテンツ セキュリティ ポリシー (CSP) の説明

サイバーセキュリティの脅威が急速に進化しているため、オンライン プレゼンスを保護するには、単一の防御層に頼るだけではもはや十分ではありません。 これにより、Web サイトの所有者は、多層防御の概念によって最もよく表される多層セキュリティ アプローチを持つことが不可欠になります。

Web サイトおよび Web アプリケーションでは、クライアント側で追加のセキュリティ制御を実施するように特別に設計された HTTP セキュリティ応答ヘッダーを使用して、多層防御を実装できます。 HTTP 応答ヘッダーは、Web アプリケーションを標的とするサイバー攻撃に対する重要な第 2 の防御線です。

主要な HTTP セキュリティ レスポンス ヘッダーの 1 つとして、コンテンツ セキュリティ ポリシー (CSP) は、クロスサイト スクリプティング (XSS) やデータ インジェクション攻撃の壊滅的な結果から Web サイトとその訪問者を効果的に保護できます。

このガイドでは、コンテンツ セキュリティ ポリシーが主要な HTTP セキュリティ ヘッダーである理由と、サイトに多層防御を実装して、WordPress を標的とするさまざまな高度なサイバー攻撃をうまく軽減する方法について説明します。

HTTP 応答ヘッダーとは何ですか?

HTTP 応答ヘッダーは、ブラウザーが要求されたコンテンツと対話する方法を定義する Web サイトおよび Web アプリケーションに実装される一連のコントロールです。 HTTP 応答ヘッダーを実装すると、Web サイトの所有者はユーザー エクスペリエンスを大幅に改善し、Web サイトの機能、パフォーマンス、およびセキュリティを向上させることができます。

Web サイトの訪問者が要求したコンテンツとともに小さな情報が送信されると、HTTP 応答ヘッダーによって、ブラウザーが Web サーバーから受信した応答を解釈および処理する方法が変更されます。 Web サイトのコンテンツと機能は変更されていませんが、HTTP 応答ヘッダーを実装すると、ユーザーの認識が変わる可能性があります。

セキュリティの脅威に対する第 2 層の防御としての HTTP セキュリティ レスポンス ヘッダー

コンテンツ セキュリティ ポリシーなどの HTTP 応答ヘッダーが使用される重要な領域の 1 つは、Web サイトのセキュリティです。 HTTP 応答ヘッダーが提供する強力な機能により、WordPress のような動的 Web アプリケーションを標的とする多くのサイバー攻撃に対する重要な第 2 の防衛線になります。

サイバー攻撃に対する防御の最前線は、攻撃対象領域を縮小し、アプリケーション レベルの脆弱性を排除する、多数のコード ベースおよびサーバー側のセキュリティ対策で構成されます。 これには、安全なコーディング プラクティスの使用、強力なアクセス制御ポリシーの確立、受信リクエストを検査して悪意のあるトラフィックを除外するための Web アプリケーション ファイアウォールの実装が含まれます。

また、強力な第一線の防御を行うことは絶対に不可欠ですが、単一のセキュリティ レイヤーに頼っていると、ますます巧妙化する攻撃に対して Web サイトが脆弱なままになる可能性があります。 特に、攻撃者がパッチを適用していない脆弱性を特定して悪用できる場合は、単一のセキュリティ制御を簡単に回避できます。

コンテンツ セキュリティ ポリシーおよびその他のセキュリティ レスポンス ヘッダーは、悪意のある攻撃による被害を軽減することで、追加の保護層を提供します。 悪意のあるハッカーが Web サイトの脆弱性をうまく特定できた場合、強力な第 2 の防御線により、攻撃者がそれを悪用することははるかに困難になります。

コンテンツ セキュリティ ポリシーとは何ですか?

コンテンツ セキュリティ ポリシー (CSP) は、Web サイトまたは特定の Web ページの読み込みが許可されているコンテンツの信頼できるソースのリストと、そのために使用されるプロトコルを定義するために使用されるセキュリティ メカニズムです。 これには、スクリプト、スタイルシート、画像、および Web ページに埋め込むことができるその他の種類のコンテンツが含まれます。

コンテンツ セキュリティ ポリシーは、現在の Web サイトの外部にあるコンテンツに対する不正な要求をブロックするのに役立つ、強力な多層セキュリティ コントロールです。 これに加えて、CSP はインライン スクリプトの実行を正常に防止し、安全でない動的コードの実行を制限します。

HTTP セキュリティ応答ヘッダーとして、CSP は、Web サイトの所有者によって構成された指示を訪問者のブラウザーに渡します。 次に、ブラウザは指示に従い、コンテンツ セキュリティ ポリシー ルールによって許可されていないコンテンツの配信をブロックする必要があります。 このようにして、ブラウザーは、特定のコンテンツが Web ページによって参照されていることを認識しますが、そのコンテンツの読み込みを拒否します。

コンテンツ セキュリティ ポリシーが重要な理由

防御の第 2 線として、コンテンツ セキュリティ ポリシーは、ほとんどの場合、攻撃者による Web サイトの侵害を防ぎません。 それでも、マルウェア感染による壊滅的な結果を軽減し、ハッカーによる悪用の試みを阻止するのに役立ちます。

機密情報を盗んだり、その他の悪意のあるアクティビティを実行したりする目的でマルウェアが Web サイトに挿入された場合でも、堅牢な CSP ポリシーにより、あなたとあなたの顧客を安全に保つことができます。 悪意のあるアクターは、Web サイトに対する顧客の信頼を悪用することはできません。ブラウザーは悪意のあるコードの実行を最初からブロックするからです。

Web サイトを完全に制御できる状態に戻し、侵害された後にマルウェアのクリーンアップを実行する間、Web サイトを悪用しようとするハッカーの試みを無効にする機能により、Content Security Policy の実装が最新の Web サイトや Web アプリケーションを保護するための強力なツールになります。

CSP は何から保護しますか?

コンテンツ セキュリティ ポリシーは、マルウェア感染によって促進されるさまざまなサイバー攻撃や、攻撃者が制御するリソースでホストされている悪意のあるスクリプトに依存する侵入の試みから、Web サイトとその訪問者を保護します。 これには、クロスサイト スクリプティング (XSS)、ファイル インクルージョン攻撃、およびコンテンツ セキュリティ ポリシーによって緩和される上位 3 つの攻撃ベクトルとしてのクリックジャッキングが含まれます。

クロスサイト スクリプティング (XSS)

クロスサイト スクリプティング (XSS) は、悪意のあるコードを Web ページに挿入するインジェクション攻撃です。 Web ページが読み込まれると、コードがブラウザによって実行され、攻撃者が機密情報を盗んだり、ユーザー セッションをハイジャックしたり、マルウェアを配布したりできるようになります。

クロスサイト スクリプティング攻撃を実行するために、ハッカーは HTML に埋め込まれたインライン スクリプトとしてマルウェアを挿入するか、通常は攻撃者が制御する Web サイトでホストされている外部スクリプトを参照することができます。 コンテンツ レンダリングのプロセス中に、悪意のあるコードがユーザーのブラウザーに読み込まれ、ユーザーの知らないうちに同意なしに実行されます。

WordPress サイトの所有者に影響を与えるクロスサイト スクリプティング攻撃の良い例の 1 つは、カード スキミング マルウェアを WooCommerce チェックアウトに挿入することで、購入者の支払い情報を盗むことです。 クロスサイト スクリプティング攻撃を実行するために使用されるカード スキマーやその他の種類の JavaScript スニファーは、通常、Web ページのソース コードでは次のようになります。

 <script type="text/javascript" src="https://hackerswebsite/evil.js"></script>

インライン スクリプトの場合、悪意のあるコードがスクリプト タグに埋め込まれているか、スタイル タグを使用してスタイルシートに偽装されていることがわかります。

クロスサイト スクリプティングの緩和は、コンテンツ セキュリティ ポリシーを実装する主な目標です。 コンテンツ セキュリティ ポリシー (CSP) は、インライン スクリプトの実行、eval 関数を使用して挿入された安全でない Javascript、および信頼されていないソースから読み込まれたスクリプトのブロックを防止することにより、Web サイトでの任意のコード実行のリスクを効果的に軽減します。

ファイル インクルージョン攻撃

ファイル インクルージョン攻撃は、コンテンツ セキュリティ ポリシーで緩和できる別のタイプのインジェクション攻撃です。 侵入手法として、リモート ファイル インクルージョン攻撃により、ハッカーは Web サイトのさまざまな領域で不十分な入力検証を悪用し、外部リソースでホストされている悪意のあるコードを実行できます。

リモート ファイル インクルージョン攻撃は、多くの場合、Web シェル バックドアをインストールして Web サイトに侵入することを目的として、WordPress プラグインおよびテーマのパッチが適用されていない脆弱性を悪用します。 クロスサイト スクリプティングの緩和と同様に、コンテンツ セキュリティ ポリシーは、すべての疑わしい外部スクリプトが Web サイトに挿入されるのを効果的にブロックするため、攻撃者がリモート ファイル インクルージョン (RFI) の脆弱性を悪用することはほとんど不可能になります。

クリックジャッキング

Web サイトの所有者がコンテンツをロードする信頼できるリソースのリストを定義できるようにするだけでなく、コンテンツ セキュリティ ポリシーは、Web サイトのコンテンツをフレーム内に埋め込むことを許可されている Web サイトのリストを制限するのに役立ちます。 これにより、スピア フィッシング攻撃で顧客に送信された疑わしいリンクを開くことで顧客が犠牲になる可能性がある、クリックジャッキングなどのユーザー インターフェイス (UI) 修復攻撃を軽減できます。

コンテンツ セキュリティ ポリシーのframe-ancestorsディレクティブは、現在ほとんどの最新のブラウザーで非推奨となっているX-Frame-Optionsヘッダーを正常に置き換えました。 これと他の CSP ディレクティブは、WordPress のセキュリティにおいて絶対に不可欠です。

コンテンツ セキュリティ ポリシー ディレクティブ

コンテンツ セキュリティ ポリシーは、ディレクティブと呼ばれる一連のルールを指定して、Web サイトがロードできるコンテンツのソースを制御するのに役立ちます。 コンテンツ セキュリティ ポリシー ディレクティブは、要求された Web ページの HTTP ヘッダーに含まれる命令のリストであり、ブラウザがそのページにロードできるコンテンツの種類と、そのページをロードできる信頼できるソースのリストを定義します。

利用可能なさまざまなコンテンツ セキュリティ ポリシー ディレクティブの中で、以下のルールは、クロスサイト スクリプティング (XSS)、クリックジャッキング、およびデータ インジェクション攻撃から Web サイトを保護するために最も一般的に適用されます。 次の CSP ディレクティブはすべて、 frame-ancestors 、 form-action 、およびupgrade-insecure-requestsを除いて、コンテンツをロードするリソースのリストを指定するフェッチ ディレクティブです。 Frame-ancestorsとform-actionコンテンツ セキュリティ ポリシーが構成されている Web サイトのコンテンツを他のリソースがどのように使用できるかを定義するナビゲーション ディレクティブです。

• default-src特定のタイプのコンテンツに対して追加のルールが指定されていない場合にブラウザがデフォルトで使用するすべてのタイプのリソースをロードするためのポリシーを定義します。
• script-src Web サイトからロードできる JavaScript ファイルの信頼できるソースを指定します。
• style-srcスタイルシート (CSS) の有効なソースのリストを定義します。
• img-srcイメージをロードできるリソースのホワイトリストです。
• media-src HTML の<audio>要素と<video>要素に埋め込まれたオーディオ ファイルとビデオ ファイルの信頼できるソースを指定します。
• connect-src XMLHttpRequest 、 EventSource 、およびWebSocket接続を制御します。
• child-srcフレームを通じて Web ページに含めることができるコンテンツのソースを定義します。
• frame-ancestors Web サイトのコンテンツをフレーム内に埋め込むことを許可するリソースのリストを指定することで、クリックジャッキング攻撃を軽減するのに役立つナビゲーション ディレクティブです。
• form-action Web フォームが情報を送信できるリソースを制限し、攻撃者が制御する外部リソースへのデータ流出を防ぎます。
• upgrade-insecure-requests安全でないすべてのリクエストをHTTPSにアップグレードするようブラウザに指示し、安全な接続を確保します。

Web サイトの種類とそれが提供する特定の機能に応じて、Web サイトの所有者は、外部から取得されたコンテンツのすべてのソースを制御するために、複数のディレクティブを構成する必要がある場合があります。

コンテンツ セキュリティ ポリシーを第 2 の防御線として使用して、クロス スクリプティングおよびインジェクション攻撃から十分に保護するための業界標準はdefault-srcディレクティブを介してのみ、外部コンテンツの有効なソースを現在の Web サイトに制限することです。 よりターゲットを絞ったディレクティブを使用して、特定の種類のコンテンツのリソースをホワイトリストに登録できますが、他のすべてのリソースを拒否することをお勧めします。

コンテンツ セキュリティ ポリシー ディレクティブの構成

各コンテンツ セキュリティ ポリシー ディレクティブは、Uniform Resource Locator (URL) で表される値のリストを受け入れます。これには、プロトコル、ドメイン名、ワイルドカード、または'self'や'none'などの特定の値が前に付いた有効な Web アドレスが含まれている必要があります。 'none' HTTP 応答ヘッダーによって提供されます。

コンテンツ セキュリティ ポリシー ディレクティブに割り当てることができる値の例を次に示します。

デフォルトでは、指定されたルールに関係なく、コンテンツ セキュリティ ポリシーはインライン スクリプトの実行をブロックし、悪意のあるハッカーが一般的に使用する eval などのテキストから JavaScript への関数を Web ページが実行できないようにします。 'unsafe-inline'および'unsafe-eval'値をscript-srcコンテンツ セキュリティ ポリシー ディレクティブに追加すると、Web サイトの所有者が制限を回避するのに役立ちますが、Web サイトが重大なセキュリティ リスクにさらされ、他のディレクティブによって課される保護が損なわれる可能性があります。 .

次の Content Security Policy ヘッダー構成は、Web サイトが外部リソースからコンテンツをロードするのを効果的に防止し、インライン スクリプトと安全でない JavaScript の実行を禁止します。

Content-Security-Policy "default-src 'self' https://mywebsite.com; frame-ancestors 'self'"

'self'値を指定すると、frame-ancestors ディレクティブは、コンテンツのフレーミングをブロックすることでクリックジャッキング攻撃を軽減します。

コンテンツ セキュリティ ポリシーとコンテンツ配信ネットワーク (CDN)

Cloudflare などのほとんどのコンテンツ配信ネットワークは、コンテンツ セキュリティ ポリシーと完全に互換性があり、オリジン サーバーからの CPS ヘッダーを変更しません。 構成するセキュリティ ルールで追加のリソースをホワイトリストに登録する必要はありません。

WordPress のコンテンツ セキュリティ ポリシーの実装

WordPress には、HTTP 応答ヘッダーを追加するためのさまざまなプラグインが用意されています。これは、技術に詳しくないユーザーに適したオプションです。 これは便利なオプションですが、WordPress Web サイトのコンテンツ セキュリティ ポリシーなどのセキュリティ レスポンス ヘッダーの設定は、サードパーティ ソフトウェアをインストールする必要がない簡単なプロセスです。

mod_headers Apache モジュールとngx_http_headers_module Nginx モジュールを使用すると、Web サイトの HTTP 応答ヘッダーを構成できます。 Nginx を使用している場合は、ウェブサイトのサーバー {} ブロックにadd_headerディレクティブを含めて、HTTP 応答ヘッダーを構成できます。

同様に、Web サーバーとして Apache を使用する場合、"Header set" および "Header append" ステートメントを使用して、ドキュメント ルートにある Web サイトのローカル.htaccessファイルでセキュリティ ポリシーを構成できます。 このようにして、Web サイトのルート ディレクトリにある .htaccess ファイルで指定された構成が、サイトのすべての Web ページに適用されます。

Apache を使用すると、HTTP 応答ヘッダーをローカル ( .htaccessファイル) とサーバー上のすべての Web サイトのグローバルの両方で構成できることに注意してください。 特に共有ホスティング プランを使用している場合は、ホスティング プロバイダーが特定の応答ヘッダーをグローバルに構成する可能性があります。 「ヘッダー セット」メソッドを使用してコンテンツ セキュリティ ポリシーを構成すると、既存のグローバル ルールが完全に上書きされますが、「ヘッダー追加」を使用すると、構成全体を置き換える代わりに、新しいポリシーが既存の応答ヘッダーにマージされます。

以下のコンテンツ セキュリティ ポリシー構成を追加して、WordPress Web サイトに厳格なセキュリティ制御を適用できます。

アパッチの場合:

 Header set Content-Security-Policy "default-src 'self' https://mywebsite.com; frame-ancestors 'self';"

Nginx の場合:

 add_header Content-Security-Policy "default-src 'self' https://mywebsite.com; frame-ancestors 'self';"

Web サイトのセキュリティ ニーズを満たすコンテンツ セキュリティ ポリシーの設定を行うには、Web サイトの機能を完全に理解するだけでなく、いくつかのテストが必要になる場合があります。 さらに、WordPress サイトに新しいセキュリティ プロトコルを実装すると、機能が失われる可能性があるため、変更の影響を慎重に検討することが重要です。 ホスティング プロバイダーに連絡するか、開発者に連絡して、セキュリティ ヘッダーが適切に構成されていて、悪影響が生じていないことを確認してください。

iThemes Security Pro で多層防御を実装する

今日の脅威の状況では、多層防御戦略を採用することが重要です。 WordPress のような最新の動的 Web アプリケーションに関して、Content Security Policy ヘッダーは多層防御の中心であり、クロスサイト スクリプティング (XSS)、ファイル インクルージョン攻撃、クリックジャッキング、およびその他の Web ベースの攻撃に対する保護の重要なレイヤーを提供します。

包括的な多層防御ソリューションの実装は常に困難でした。 しかし、堅牢で信頼性の高いセキュリティ プラグインである iThemes Security Pro を使用すると、WordPress Web サイトを保護できます。 ファイル整合性監視、脆弱性スキャン、ソフトウェアの自動更新、パスワードレス認証などの機能により、WordPress Web サイトのすべての重要な部分が進化し続けるセキュリティの脅威から保護されていることを確信できます.

WordPress を安全に保護するための最高の WordPress セキュリティ プラグイン

WordPress は現在、すべての Web サイトの 40% 以上で使用されているため、悪意のあるハッカーにとって格好の標的となっています。 iThemes Security Pro プラグインは、WordPress のセキュリティから当て推量を取り除き、WordPress Web サイトを簡単に保護および保護できるようにします。 これは、WordPress サイトを常に監視して保護するフルタイムのセキュリティ専門家がスタッフにいるようなものです。

iThemes Security Pro を入手

キキ・シェルドン

Kiki は情報システム管理の学士号を取得しており、Linux と WordPress で 2 年以上の経験があります。 彼女は現在、Liquid Web と Nexcess のセキュリティ スペシャリストとして働いています。 それ以前は、Kiki は Liquid Web Managed Hosting サポート チームの一員であり、何百人もの WordPress Web サイト所有者を支援し、彼らがよく遭遇する技術的な問題について学びました。 彼女の執筆への情熱により、彼女は自分の知識と経験を共有して人々を助けることができます。 テクノロジーとは別に、キキは宇宙について学んだり、真の犯罪に関するポッドキャストを聞いたりすることを楽しんでいます。