混合コンテンツの修正

Jo-el van Bergen
Jo-el van Bergen
X
Rachel Andrew

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

このガイドでは、既存の混合コンテンツの問題を修正し、新しい問題が発生しないようにするための手法とツールについて説明します。

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

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

混合コンテンツとはで、さまざまな例と、Chrome DevTools で問題がどのように報告されるかを確認できます。

パッシブな混合コンテンツの例では、次の警告が表示されます。ブラウザが https URL でコンテンツを見つけられる場合は、自動的にアップグレードし、メッセージを表示します。

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

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

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

サイトの http:// 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 ヘッダーを含めることで、ページでこれらの機能を有効にすることができます。また、ページの <head> セクションで <meta> タグを使用して Content-Security-Policy を設定することもできます（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 や Mixed Content Scan など、ウェブサイト クローラを使用してサイトの問題を見つける方法があります。

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

対応ブラウザ

  • Chrome: 44。
  • Edge: 17.
  • Firefox: 48.
  • Safari: 10.1。

ソース

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

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

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

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

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

Content-Security-Policy: upgrade-insecure-requests

または、<meta> 要素を使用して、ドキュメントの <head> セクションにこの同じディレクティブをインラインで埋め込みます。

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

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

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