セキュリティ関連の HTTP ヘッダーの意義と Amazon CloudFront での設定方法

作成したレスポンスヘッダーポリシーやマネージドポリシーを、ディストリビューションのビヘイビアに設定することで、URL パスごとにレスポンスヘッダーをカスタマイズすることができます。

これらのセキュリティヘッダーを構成することで、Web ブラウザに対してリソースの取り扱い方法を指示し、クロスサイトスクリプティングやクリックジャッキングなどの攻撃に対する防御策、保険的対策として利用できます。

Web サイトを構成する要素に、<frame> や <iframe> などのフレーム要素があります。

この要素を利用することで、サイト内の一部要素に別の HTML ファイルを埋め込むことが可能となります。たとえば、ヘッダー部分などの共通部分をフレームにしたり、ソーシャルネットワーキングサービス (SNS) のコンテンツをページ内に表示するために利用されています。

これを悪用した攻撃の一つに、Webサイトの利用者に意図しないクリックをさせる クリックジャッキング という攻撃があります。

この攻撃は、攻撃者が作成した広告や Web サイトなどに重ねて、CSS 設定で透明にした SNS の投稿ボタンや通販サイトの購入ボタンなどを配置することで、利用者が広告に釣られて透明の SNS の投稿ボタンや通販サイトの購入ボタンなどを誤ってクリックするように誘導するものです。これによって、意図しない SNS 投稿や通販サイトでの購入を行ってしまうリスクがあります。

X-Frame-Options を利用することで、フレーム内での該当Webサイトの利用を完全に拒否 (DENY) したり、Web ページと同じオリジンの場合のみ許可 (SAMEORIGIN) することが可能となります。

ヘッダーやフッターなど、オリジン範囲の別ページを表示するような一般的な用途であれば、オリジン範囲の Web ページは管理者によって管理されているため、SAMEORIGIN を指定して、Web ページと同じオリジン範囲内で許可すれば問題ありません。

上記を参考に、意図しないページからのフレーム利用を制限してください。

Web ブラウザは、CDN の提供する静的コンテンツやスクリプト (JavaScript 等) などのほか、3rd party が提供する Web API など、多くのリソースを利用してユーザーに対して Web ページを構成し、提供しています。

コンテンツを提供するサーバー側から、コンテンツを提供するサーバーと異なるオリジンからのコンテンツ利用の可否をブラウザに対して指示する方法については、前編の 「クロスオリジンリソース共有 (CORS)」で確認しました。

ここでは、Web ページを読み取る際に、リソースの提供元を指定することにより、リソースの提供元を信頼できるサイトに限定することを可能とする方法を見ていきます。

提供元を信頼できるサイトに限定することで、Web サイトが XSS (クロスサイトスクリプティング) などの攻撃にあった際も、リソースの提供元が限定されているため、攻撃者の用意したスクリプトの実行による攻撃者の用意したサーバーへの情報漏洩などを防ぐことが可能となります。

Content-Security-Policy ヘッダーには、コンテンツの取得元を許可する範囲を指定する、以下のような Policy を記載します。

よく使われるところでは、すべての Directive のデフォルト Policy を与える default-src と、同一オリジンを指定する 'self' の組み合わせです。この指令によりスクリプトなどがサイト自身のオリジンからのみ読み込まれるようになります。ただし、この設定の場合、HTMLページ内に記述された JavaScript も禁止されるため、注意が必要です。

フェッチディレクティブは、参照先のリソース種類を指定するもので、画像を表す img-src や、スクリプトを表す script-src などが用意されています。また、ナビゲーションディレクティブではフレームの親を指定する frame-ancestors が用意されるなど、多様な設定が可能です。例えば、 frame-ancestors 設定を利用することで、前述のクリックジャッキング対策も実装可能です。

さらに、Web API として、Amazon API Gateway endpoint を利用している場合などは、 ナビゲーションディレクティブの form-action や フェッチディレクティブの connect-src を指定することで、 Web API の通信先を Amazon API Gateway に限定することが可能となります。

CSP の構文は多くの指定ができるため、詳細は 一般的な適用例 や 関連ディレクティブ をご確認ください。

CSP を用いることで、画像やスクリプト、通信先など、リソースの種類ごとに接続先を限定することが可能です。

適切な CSP の構成により、XSS などの攻撃を受けた際にも、攻撃者の用意したリソースへのアクセスを制限することが可能となります。意図しないリソースへのアクセスを防ぐためにも、是非 Content-Security-Policy を構成いただき、適切な設定を行ってください。

X-XSS-Protection ヘッダーを利用した場合、ブラウザの持つ XSS フィルタリング機能を有効化し、ページの無毒化 (サニタイズ) を行ったり、レンダリングを停止するなどの対策を行います。

このセキュリティヘッダーは主要なブラウザにおいて機能が実装されていなかったり、新しいバージョンでは廃止されていたりと、標準機能ではありません。このため、2024 年現在においては非推奨であり、 CSP により代替されています。

CSP による制限をつけた Web サイトでは、全てのインラインスクリプトの実行を許可する unsafe-inline などの unsafe キーワードを利用しない限り、HTML ファイル内のインラインリソースや eval などの危険なコードが利用できなくなるため、XSS の被害を防止するのに役立ちます。

現在の Web サイトでは、CSP の利用を原則として検討してください。古いバージョンのブラウザ利用を検討する必要がある場合にのみ、本ヘッダーの利用を考慮に入れる必要があります。その場合には上述の説明やリンクを参考に設定を行ってください。

Web サーバーは、コンテンツの種類を Content-Type としてブラウザに提示します。

例えば、HTML ファイルであれば Content-Type: text/html 、PDF であれば Content-Type: application/pdf などが指定されます。この値は、 MIME タイプ に記載があります。

しかし、すべてのサーバーが適切な Content-Type を返すわけではないため、ブラウザには MIME スニッフィング という機能が搭載されています。

この機能は、MIME タイプが提供されていない場合や、誤りであると考えられる場合に Web ブラウザが正しい値を推測するものです。

この機能は、通常であれば可用性を高めるために有用なのですが、ブラウザによってコンテンツが本来意図していない形式で解釈されてしまうと、攻撃者の用意したファイルを不正に実行してしまう懸念があります。

例えば、画像ファイルなどをアップロードできるシステムに対して攻撃者が不正なファイルをアップロードし、利用者がダウンロードした際に、ブラウザがコンテンツタイプを JavaScript が実行可能な HTML と解釈することで、不正なスクリプトを実行される懸念があります。
このように、システムが画像を表す Content-Type: image/png を指定していたとしても、ブラウザが Content-Type の誤りとして、JavaScript として処理、実行してしまう攻撃などが想定されます。

X-Content-Type-Options を有効にした場合、Web ブラウザは MIME スニッフィングを実施しません。

これにより、攻撃者がアップロードしたファイルが、Content-Type で指定された MIME タイプと異なった場合でも、 Web ブラウザは Content-Type の通り処理し、その処理に失敗します。

適切な Content-Type の構成により、Web ブラウザでリソースが適切に処理されるようになります。Content-Type を正しく提供するとともに、X-Content-Type-Options を指定して、MIME スニッフィングを抑止してください。

前編に引き続き、Amazon CloudFront では簡単にセキュリティヘッダーを構成して Web ブラウザを保護できることをご紹介しました。

今回紹介した中で、Content-Security-Policy (CSP) は特に強力な機能です。しかし、他のセキュリティヘッダーが数クリックで設定できるのに対して、現行の UI で CSP を利用するには policy を自身で作成することが必要なため、本記事や参考資料を見ながら適切に設定してください。

Amazon CloudFront のセキュリティポリシーは追加費用なしに利用できる強力なセキュリティ機能です。

ご自身で設定されない場合でも、信頼できるパートナー企業を選定するなどして、安全に AWS を活用してみてください。