HTTPレスポンスヘッダーがセキュリティに与える影響

著者

2023年5月3日

0 分で読めます

WebサーバーがHTTPリクエストを受け取ると、そのリクエストを処理し、要求されたリソースと追加情報を含むレスポンスを返します。追加情報はHTTPレスポンスヘッダーとして送信されます。これらのヘッダーには、最終更新日、コンテンツタイプ、キャッシュ制御の設定など、重要なデータが含まれています。ブラウザーはこの情報を使って、該当するリソースの表示方法や保存方法を決定します。この仕組みにより、Webサーバーとブラウザー間の効率的な通信が実現します。

サイバーセキュリティの観点から見ると、HTTPレスポンスヘッダーは攻撃対象となる可能性がある一方、防御をさらに強化する機会にもなります。認証トークン、Cookie、セッションIDなどの機密データが含まれる場合があり、これらにアクセスした攻撃者は、認可制御を回避したり、ユーザーアカウントを乗っ取ったりすることができます。一方で、ヘッダーを使ってキャッシュを制御し、返されるコンテンツの種類を指定することで、クロスサイトスクリプティング（XSS）やクリックジャッキングなどの攻撃を防ぐこともできます。

HTTPレスポンスヘッダーには、認証、ユーザーエージェントの追跡、XSSの防止、HTTPSの使用強制など、さまざまなセキュリティ機能があります。Etag、Last-Modified、Content-Typeなど、セキュリティ対策には役立たないHTTPヘッダーもありますが、Content Security Policy（CSP）、HTTP Strict Transport Security（HSTS）、X-Frame-Optionsヘッダーは、サーバーの防御を強化するために活用できます。

この記事では、セキュリティに影響する複数のHTTPヘッダーを取り上げ、HTTPレスポンスヘッダーを活用してWebアプリケーションを保護するためのベストプラクティスを紹介します。

セキュリティ対策にHTTPレスポンスヘッダーを活用する

HTTPレスポンスヘッダーを使えば、悪用される可能性のあるさまざまな脆弱性のリスクを軽減できます。

HTTPレスポンスヘッダーに関連する脆弱性

適切なHTTPレスポンスヘッダーは、直接的な攻撃を防ぐだけでなく、ヘッダーが直接関与しない脆弱性への対策にもなります。攻撃や脆弱性の例をいくつか紹介します。

クロスサイトリクエストフォージェリ（CSRF）：攻撃者は、ワンクリック攻撃とも呼ばれるCSRFを使って、ユーザーのWebブラウザーに本人の意図しない操作を実行させることができます。
セッションハイジャック：攻撃者は、認証済みユーザーのセッションIDを盗んで既存のセッションを乗っ取ることで、不正アクセスを実行します。ユーザー名とパスワードの組み合わせなどの認証情報は必要なく、従来の認証システムを回避できます。
データ漏えい：HTTPレスポンスヘッダーには、パスワード、クレジットカード番号などの機密情報が含まれる場合があります。適切に設定されていなければ、こうした情報が漏えいする恐れがあります。
中間者（MITM）攻撃：攻撃者はMITM攻撃によって、取引中に当事者間の通信を傍受、改ざん、遮断します。どちらの当事者も、相手が不正な第三者と通信していることに気づきません。
クリックジャッキング攻撃：WebサイトのHTMLフレームセットの脆弱性を悪用し、攻撃者が偽のコンテンツをユーザーに表示させます。ユーザーがクリックすると、意図しない操作を実行させられたり、気づかないうちに機密情報を開示させられたりします。

潜在的な攻撃経路が数多く存在するなか、Webアプリケーションのセキュリティを維持することは非常に重要です。ここ数年で、影響の大きい重大なセキュリティ侵害が増加しています。たとえば、次のような事例があります。

最近、信用情報会社TransUnionで発生したデータ漏えいでは、攻撃者が南アフリカの5000万人以上の個人情報を人質に取り、1500万ドルの身代金を要求しました。
GDPR関連のWordPressプラグインは、XSS攻撃やCSRF攻撃の影響を受ける可能性があります。あるプラグインは2018年に1万件のWebサイトに影響し、別のプラグインは2020年に70万件のWebサイトの情報を漏えいさせました。
大手テクノロジー企業は常に魅力的な標的です。幸い、配車サービス企業Uberでは、CSRFとセッションハイジャックの脆弱性によるコストは支払われたバグ報奨金の約5000ドルにとどまりました。

攻撃が頻繁に、そして大規模に発生していることを踏まえると、HTTPヘッダーを含むセキュリティ対策の強化と維持は、欠かせない取り組みです。

セキュリティに影響するHTTPレスポンスヘッダー

データ漏えいは、HTTPレスポンスヘッダーに直接関係する脆弱性です。CSRF、セッションハイジャック、MITM攻撃は、必ずしもHTTPレスポンスヘッダーを伴うものではありません。しかし、CSPやHTTP Strict Transport Security（HSTS）などのセキュリティヘッダーを使用し、以下に挙げるようなセキュリティに影響する他のヘッダーをベストプラクティスに沿って利用することで、こうした攻撃も軽減できます。

HTTP Strict Transport Securityヘッダー

HSTSレスポンスヘッダーは、MITM攻撃、データ漏えい、クリックジャッキングからアプリケーションを保護します。このヘッダーは、ブラウザーとサーバー間のすべての通信を、平文のHTTPではなくHTTPS接続で行うよう強制します。これにより、攻撃者が悪意のあるプロキシサーバーを経由するよう通信をリダイレクトし、当事者に気づかれずに送受信される機密データにアクセスしたり、改ざんしたりするのを防ぎます。

HSTSには、次のようなWebサイトのセキュリティポリシーに関する情報が含まれます。

接続が有効な期間（max age）。
保護の対象にサブドメインを含めるかどうか。
受け入れる証明書の種類。

HSTSレスポンスヘッダーを最大限に活用するには、必ず最大有効期間を設定します。この値は、次のリクエストがTLS/SSLトンネルを通じて送信される前に、クライアントが安全な接続を行うよう記憶しておく期間に合わせます。

Content-Security-Policyヘッダー

CSPは、さまざまな種類の攻撃から防御するうえで重要です。開発者は、許可するリソースとそのオリジンをセーフリストに登録し、ディレクティブを定義できます。また、インラインスクリプトやeval()を許可するか、HTMLのstyle属性を認めるかどうかも指定できます。

HTTP Content-Security-Policyレスポンスヘッダーを使用すると、Webサイトのコンテンツで許可またはブロックするドメインとリソースを指定できます。XSSや前述の脆弱性に加え、クリックジャッキング、データインジェクション、コードインジェクション、CSRF、機密情報への不正アクセスなど、その他の悪意ある行為からも保護します。CSPには、スクリプト、画像、その他悪用可能なアセットの読み込みなど、ドメイン外の信頼できない送信元からのリクエストをブラウザーがどのように処理するかを定めるディレクティブが含まれます。

脆弱性から積極的に防御するための、CSPヘッダーの設定ガイドラインを紹介します。

可能な限り、許可するポリシーではなくブロックするポリシーを選びましょう。これにより、デフォルトでドメイン外の信頼できない送信元からのリクエストをブロックできます。
ワイルドカードのサブドメインを使用します（メインドメイン名の前に*.<your-domain-name>を付けます）。
リクエストを無差別に広く許可するのではなく、既知の信頼できる送信元だけにアクセスを制限します。また、スクリプト、画像、その他悪用可能なアセットの読み込みなど、ドメイン外の信頼できない送信元からの特定のリクエストをブラウザーがどのように処理するかを定めるディレクティブも設定します。

厳格なセキュリティ対策を講じることで、許可されたクライアントだけが機密情報を閲覧できるようにし、意図しない下流経路を介したデータ漏えいを防げます。また、Subresource Integrity（SRI）などの厳格な検証メカニズムを利用すれば、Webサイトのリソースの整合性を検証し、攻撃者による改ざんがないことを確認できます。

SRIとCSPを組み合わせることで、信頼でき、改ざんされていないサードパーティのリソースだけがWebページに読み込まれるようにできます。

X-Content-Type-Optionsヘッダー

X-Content-Type-Optionsヘッダーを利用すると、配信されたファイルやコンテンツの種類をブラウザーが自動判別しないよう指示できます。これにより、ブラウザーが任意のスクリプトファイルを解析・実行できなくなるため、攻撃者がWebサイトに悪意あるコードを注入することが難しくなります。このように、X-Content-Type-Optionsヘッダーは、悪意あるコンテンツやXSS攻撃に対する最前線の防御となります。

このヘッダーを設定して利用する際は、すべてのサイトで厳密に指定したMIMEタイプを使ってコンテンツを配信してください。可能な限り、値にワイルドカード（*）を使用しないようにします。実際のファイルタイプを指定すれば、ブラウザーはどのようなアセットを想定すべきかを正確に把握でき、種類を判別する必要がなくなります。

X-Frame-Optionsヘッダー

X-Frame-Optionsは、クリックジャッキング攻撃からWebアプリケーションを保護します。このヘッダーには、第三者のWebサイトにある<iframe>要素内にコンテンツを表示するかどうかをブラウザーに伝えるディレクティブが含まれています。

よく使われるディレクティブは2つあります。DENYは、他のサイトで要求されたリソースをフレーム内に表示する試みをすべて拒否します。SAMEORIGINは、両方のページが同一オリジンポリシーのもとでホストされている場合にのみリクエストを許可します。この設定は、クリックジャッキングやその他のXSS関連のセキュリティ脆弱性への対策に役立ちます。

Webアプリケーションが配信するすべてのリソースに、常にX-Frame-Optionsを含めるのが最善です。SAMEORIGINではなくDENYを設定しましょう。コンテンツがオリジンポリシーの範囲外に出る状況や方法は予測できないため、デフォルトで最大限の保護を適用することも重要です。

Referrer-Policyヘッダー

Referrer-Policyヘッダーは、あるアプリケーションやWebサイトから別の場所へ移動する際に、リファラー情報がどのように伝達されるかを制御します。主なディレクティブはnone、no-referrer、no-referrer-when-downgrade、originの4つです。これらによって、ページ遷移の際にブラウザーが参照元URLを他のサイトやアプリケーションとどのように共有するかを指定できます。

ユーザーが複数のWebプロパティやドメインを移動しても機密データが誤って公開されないよう、個々のニーズに合わせてこのヘッダーを設定できます。

Referrer-Policyにはno-referrerを設定するのが理想的です。これにより、ユーザーが外部リンクをクリックした際、リクエストヘッダーにリファラー情報が含まれなくなります。意図しない経路への個人データの漏えいを防ぎ、プライバシーを守る設定です。

JavaScriptでセキュリティヘッダーを設定する

ここでは、JavaScriptで開発する際にセキュリティヘッダーを設定できるツールを3つ紹介します。以下の方法は、他のプログラミング言語やエコシステムにも適用できます。

各ツールを確認した後、実際にセキュリティヘッダーを設定する方法を例を交えて説明します。

Express.js向けHelmet

Helmetは、攻撃や脆弱性からWebアプリケーションを保護するための、セキュリティ関連HTTPレスポンスヘッダーのコレクションです。Express.js向けHelmetは、Express.jsフレームワークでの利用に特化したHelmetパッケージの拡張機能です。アプリケーションにセキュリティ関連HTTPレスポンスヘッダーを設定する、9つの小規模なミドルウェア関数を提供します。

Express.js向けHelmetの設定は簡単です。まず、次のコマンドでHelmetをインストールします。

1npm install helmet

次に、次のコードを使ってExpressフレームワークとHelmetパッケージの両方を読み込み、ミドルウェア関数を利用できるようにします。これにより、レスポンスヘッダーを設定できます。

1const express = require("express");
2const helmet = require("helmet");

次に、以下のコードを使ってExpressアプリケーションのインスタンスを作成し、変数に割り当てて、Helmetのミドルウェア関数を使い始めます。

1const app = express();
2app.use(helmet());

Helmetを初期化すると、前述の5つを含む複数のセキュリティヘッダーが設定されます。以下のコードのようにhelmet()ミドルウェアへ追加することで、Express.js向けHelmetの個々のヘッダーオプションをカスタマイズできます。

1app.use(
2  helmet({
3    X-Frame-Options: { policy: "DENY" },
4  })
5);

Fastify向けHelmet

Fastify向けHelmetは、Fastify Webフレームワークに重要なセキュリティヘッダーを追加できるミドルウェアパッケージです。基本的にはHelmetをラップしたもので、同じオプションを受け付けます。

次のコマンドを実行して、Fastify向けHelmetをインストールします。

1npm i @fastify/helmet.

次に、以下のコードを使ってFastifyフレームワークとFastify向けHelmetを読み込みます。

1const fastify = require('fastify');
2const helmet = require('@fastify/helmet');

次に、以下のコードを実行して、Helmetプラグインをアプリケーションに登録します。

1fastify.register(helmet);

このコマンドを実行すると、基本的なセキュリティヘッダーが自動的に設定されます。

check-my-headers

Check-my-headersは、WebサイトのHTTPヘッダーに潜在的な脆弱性がないか、すばやくテストできる無料のCLIツールです。無料で利用でき、フレームワークにも依存しないため、ヘッダーの設定に使用した方法を問わずチェックできます。

npm install -g check-my-headersでグローバルにインストールし、CLIでnpx check-my-headers https://yourwebsite.comと入力すれば、手軽に一度だけスキャンを実行できます。

まとめ　

Webセキュリティに影響を与える重要なHTTPレスポンスヘッダーはいくつかあります。これらをベストプラクティスに沿って活用すれば、Webアプリケーションのセキュリティをさらに強化できます。ここで取り上げた5つのヘッダーは、CSRF攻撃、セッションハイジャック、データ漏えい、中間者攻撃（MITM）、クリックジャッキングなど、重大かつ取り返しのつかない被害につながりかねないさまざまな脆弱性から保護するのに役立ちます。HTTPレスポンスヘッダーがセキュリティを弱める要因にも強化する要因にもなり得ることを理解するのは、こうした一般的な攻撃ベクトルのリスクを軽減するための重要な一歩です。

レスポンスヘッダーを適切に活用し、設定することは、Webセキュリティに欠かせません。ユーザーのプライバシーを守り、Webサーバーとクライアント間の通信をより柔軟に保護できるようにします。