混合コンテンツの修正

ウェブサイトで HTTPS をサポートすることは、攻撃からサイトとユーザーを守るうえで重要なステップです。 混合コンテンツである場合、保護が無意味になります。 混合コンテンツとはで説明されているように、安全性の低い混合コンテンツはブラウザでブロックされます。

このガイドでは、混合コンテンツの既存の問題を解決するための手法とツールについて説明します。 新たな脅威の発生を防げます

サイトにアクセスして混合コンテンツを見つける

Google Chrome で HTTPS ページにアクセスすると、 ブラウザにより、混合コンテンツがエラーと警告として JavaScript コンソールにアラートされます。

混合コンテンツとはをご覧ください。 Chrome DevTools でいくつかの例を参照し、問題がどのように報告されるかをご確認ください。

パッシブな混合コンテンツの例では、次のような警告が表示されます。 ブラウザが https の URL でコンテンツを検出できた場合は、自動的にアップグレードされ、メッセージが表示されます。

混合コンテンツが検出され、アップグレードされたときに警告を表示する Chrome DevTools

アクティブな混合コンテンツはブロックされ、警告が表示されます。

アクティブな混合コンテンツがブロックされているときに警告を表示する Chrome DevTools

サイト上の http:// URL についてこのような警告が表示された場合は、 サイトのソースで修正する必要があります これらの URL と、その URL が検出されたページのリストを作成して、修正時に使用することをおすすめします。

サイト内の混合コンテンツを見つける

混合コンテンツはソースコード内で直接検索できます。 ソースで http:// を検索し、HTTP URL 属性を含むタグを探します。 アンカータグ(<a>)の href 属性に http:// が含まれていることに注意してください。 多くの場合、混合コンテンツの問題ではありませんが、後述の重要な例外があります。

コンテンツ マネジメント システムを使用してサイトを公開している場合、 ページの公開時に、保護されていない URL へのリンクが挿入されることがあります。 たとえば、相対パスではなく完全な URL で画像が含まれている場合があります。 CMS コンテンツ内でこれらを見つけて修正する必要があります。

混合コンテンツの修正

サイトのソースで混合コンテンツが見つかったら 次の手順で解決できます。

リソース リクエストが HTTP から HTTPS に自動的にアップグレードされたことを示すコンソール メッセージが表示された場合は、 コード内のリソースの http:// URL を https:// に変更できます。 ブラウザの URL バーで http://https:// に変更して、リソースが安全に使用可能かどうかを確認することもできます。 ブラウザタブでその URL を開こうとしています。

リソースが https:// を介して利用できない場合は、次のいずれかのオプションを検討する必要があります。

  • 別のホストのリソースがある場合は、それを追加します。
  • 法的に許可されている場合は、コンテンツを直接ダウンロードしてサイト上でホストします。
  • サイトからリソース全体を除外します。

問題を修正したら 最初にエラーが見つかったページを表示し、エラーが表示されなくなったことを確認します。

標準以外のタグの使用に注意

サイトでの標準的でないタグの使用に注意してください。 たとえば、アンカータグ(<a>)の URL によって混合コンテンツ エラーが発生することはありません。 ブラウザを新しいページに移動させるとき。 つまり、通常は修正する必要はありません。 ただし、一部の画像ギャラリー スクリプトは <a> の機能をオーバーライドします。 タグを付けて、href 属性で指定された HTTP リソースをページ上のライトボックス ディスプレイに読み込む。 混合コンテンツの問題を引き起こしています。

混合コンテンツを大規模に処理する

上記の手動による手順は、小規模なウェブサイトに適しています。 大規模なウェブサイトや 複数の開発チームが存在するサイトでは 読み込まれたすべてのコンテンツを追跡するのは困難です。 このタスクには、コンテンツ セキュリティ ポリシーを使用できます を使用して混合コンテンツについて通知するようにブラウザに指示し、ページで安全でないリソースが予期せず読み込まれることがないようにします。

コンテンツ セキュリティ ポリシー

コンテンツ セキュリティ ポリシー(CSP) は、混合コンテンツを大規模に管理するために使用できる多目的のブラウザ機能です。 CSP レポート メカニズムを使用すると、サイト上の混合コンテンツを追跡できます。 混合コンテンツをアップグレードまたはブロックすることでユーザーを保護するための違反措置ポリシーを提供します。

ページに対してこれらの機能を有効にするには、 サーバーから送信されたレスポンスの Content-Security-Policy または Content-Security-Policy-Report-Only ヘッダー。 また、Content-Security-Policy を ページの <head> セクションで <meta> タグを使用します(Content-Security-Policy-Report-Only除く)。

コンテンツ セキュリティ ポリシーを含む混合コンテンツの検索

コンテンツ セキュリティ ポリシーを使用すると、サイト上の混合コンテンツのレポートを収集できます。 この機能を有効にするには、サイトのレスポンス ヘッダーとして Content-Security-Policy-Report-Only ディレクティブを追加して設定します。

レスポンス ヘッダー:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportingEndpoint

ユーザーがサイトのページにアクセスすると コンテンツ セキュリティ ポリシーに違反するものはすべて、ブラウザから JSON 形式のレポートを https://example.com/reportingEndpoint。 この場合、HTTP 経由でサブリソースが読み込まれるたびにレポートが送信されます。 このレポートには、ポリシー違反が発生したページの URL と、ポリシーに違反したサブリソース URL が含まれます。 これらのレポートを記録するようにレポート エンドポイントを設定した場合、 自分で各ページにアクセスしなくても、サイトの混合コンテンツをトラッキングできます。

次の 2 つの点に注意してください。

  • ユーザーは、CSP ヘッダーを理解しているブラウザでページにアクセスする必要があります。これは最新のブラウザのほとんどに当てはまります。
  • ユーザーがアクセスしたページに関するレポートのみを取得できます。 トラフィックが少ないページがあれば サイト全体のレポートが届くまでに時間がかかることがあります。

コンテンツ セキュリティ ポリシー で詳細とサンプル エンドポイントをご覧ください。

CSP によるレポートに代わる方法

サイトが Blogger などのプラットフォームでホストされている場合、 ヘッダーを変更して CSP を追加するアクセス権がない場合があります。 代わりに、ウェブサイト クローラを使用してサイト全体で次のような問題を検出することもできます。 HTTPSChecker または 混合コンテンツのスキャン

安全でないリクエストのアップグレード

対応ブラウザ

  • 44
  • 17
  • 48
  • 10.1

ソース

ブラウザのアップグレードが開始され、安全でないリクエストのブロックが始まっています。 CSP ディレクティブを使用して、これらのアセットの自動アップグレードまたはブロックを強制することができます。

upgrade-insecure-requests CSP ディレクティブは、ネットワーク リクエストを行う前に、安全でない URL をアップグレードするようブラウザに指示します。

たとえば、あるページに次のような HTTP URL を含むイメージタグがあるとします。 <img src="http://example.com/image.jpg">

代わりに、ブラウザは安全なリクエストを https://example.com/image.jpg: 混合コンテンツからユーザーを保存します。

この動作を有効にするには、次のディレクティブを指定して Content-Security-Policy ヘッダーを送信します。

Content-Security-Policy: upgrade-insecure-requests

または、同じディレクティブをドキュメントの <head> にインラインで埋め込むことで、 この例のように <meta> 要素を使用します。

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

ブラウザの自動アップグレードと同様に、リソースが HTTPS 経由で利用できない場合は、 アップグレードされたリクエストは失敗し、リソースが読み込まれません。 これにより、ページのセキュリティを確保できます。upgrade-insecure-requests ディレクティブは、ブラウザの自動アップグレードだけでなく、 ブラウザが現在リクエストしていないアップグレード リクエスト。

upgrade-insecure-requests ディレクティブは、<iframe> ドキュメントにカスケードされます。 ページ全体が保護されます。