脆弱性を防ぐためにセキュリティ HTTP ヘッダーを実装するにはどうすればよいですか?

セキュリティ上の脆弱性のほとんどは、応答ヘッダーに必要なヘッダーを実装することで修正できることをご存知ですか?

セキュリティは、Web サイトのコンテンツや SEO と同様に不可欠であり、構成ミスや保護の欠如により、何千もの Web サイトがハッキングされます。あなたが Web サイトの所有者またはセキュリティ エンジニアで 、クリックジャッキング、コード インジェクション、MIME タイプ、XSS などの攻撃から Web サイトを保護したいと考えている場合、このガイドは役に立ちます。

この記事では、Web サイト保護を強化するために複数の Web サーバー、ネットワーク エッジ、CDN プロバイダーに実装するさまざまな HTTP ヘッダー ( OWASP が推奨 ) について説明します。

ノート：

• 変更を加える前に、構成ファイルのバックアップを取ることをお勧めします。
• 一部のヘッダーはすべてのブラウザーでサポートされていない可能性があるため、実装する前に 互換性を確認してください 。
• これらのヘッダーを実装するには、Apache で Mod_headers を有効にする必要があります。 httpd.conf ファイル内の次の行のコメントが解除されていることを確認します。

 LoadModule headers_module modules/mod_headers.so

• 実装後、セキュア ヘッダー オンライン ツールを使用して結果を検証できます。

WordPress を使用していますか?: これらのヘッダーやその他の処理を行う HTTP ヘッダー プラグイン を 使用してみるとよいでしょう。

始めましょう…👨‍💻

HTTP の厳格なトランスポート セキュリティ

ブラウザからのすべての通信が HTTPS (HTTP Secure) 経由で送信されることを保証する HSTS (HTTP Strict Transport Security) ヘッダー。これにより、HTTPS のクリックスルー プロンプトが表示されなくなり、HTTP リクエストが HTTPS にリダイレクトされます。

このヘッダーを実装する前に、Web サイトのすべてのページが HTTPS 経由でアクセスできることを確認する必要があります。そうしないとブロックされます。

HSTS ヘッダーは、IE、Firefox、Opera、Safari、Chrome などのブラウザの主要な最新バージョンのすべてでサポートされています。パラメータ設定は 3 つあります。

パラメータ値	意味
最大年齢	リクエストが HTTPS 経由でのみ利用可能であることをブラウザーに伝える期間 (秒単位)。
サブドメインを含む	この設定はサブドメインにも有効です。
プリロード	HSTS プリロード リスト にドメインを含めたい場合に使用します。

そこで、ドメインとサブドメインのプリロードを含め、HSTS を 1 年間構成する例を見てみましょう。

Apache HTTPサーバー

httpd.conf ファイルに次のエントリを追加することで、Apache に HSTS を実装できます。

 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" 

Apacheを再起動して結果を確認します

Nginx

Nginx で HSTS を構成するには、 nginx.conf のサーバー (SSL) ディレクティブの下に次のエントリを追加します。

 add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload'; 

いつものように、確認するには Nginx を再起動する必要があります

クラウドフレア

Cloudflare を使用している場合は、数回クリックするだけで HSTS を有効にすることができます。

• Cloudflare にログインし、サイトを選択します
• 「暗号化」タブに移動し、「HSTSを有効にする」をクリックします。

必要な設定を選択すると、変更がその場で適用されます。

マイクロソフトIIS

IIS マネージャーを起動し、各サイトの「HTTP 応答ヘッダー」に移動してヘッダーを追加します。

サイトを再起動する

X フレーム オプション

X-Frame-Options ヘッダーを使用して、Web サイトでの クリックジャッキングの 脆弱性を防ぎます。このヘッダーを実装すると、Web ページを Frame/iframe に埋め込まないようにブラウザに指示できます。これにはブラウザのサポートにいくつかの制限があるため、実装する前に確認する必要があります。

次の 3 つのパラメータを設定できます。

パラメータ値	意味
同源	コンテンツのフレーム/iframe は、同じサイトのオリジンからのみ許可されます。
拒否	どのドメインでも、frame/iframe を使用してコンテンツを埋め込むことができないようにします。
許可する	特定の URI でのみコンテンツをフレーム化できるようにします。

Web ページにドメインが埋め込まれないように「 DENY 」を実装する方法を見てみましょう。

アパッチ

httpd.conf に次の行を追加し、Web サーバーを再起動して結果を確認します。

 Header always append X-Frame-Options DENY 

Nginx

nginx.conf のserver directive/blockの下に以下を追加します。

add_header X フレーム オプション “拒否”;

再起動して結果を確認する

F5 LTM

以下を使用して iRule を作成し、それぞれの仮想サーバーに関連付けます。

 when HTTP_RESPONSE {

HTTP::header insert "X-FRAME-OPTIONS" "DENY"

} 

何も再起動する必要はなく、変更は空中に反映されます。

ワードプレス

このヘッダーは WordPress を通じて実装することもできます。 wp-config.php ファイルに以下を追加します

 header('X-Frame-Options: DENY); 

ファイルの編集に慣れていない場合は、ここで説明または上で説明したプラグインを使用できます。

マイクロソフトIIS

それぞれのサイトの「HTTP 応答ヘッダー」に移動してヘッダーを追加します。

サイトを再起動して結果を確認します。

X-コンテンツタイプ-オプション

このヘッダーを Web ページの HTTP 応答に追加することで、 MIME タイプのセキュリティ リスクを防ぎます。このヘッダーがあると、ブラウザーはファイル タイプを定義されたものとみなし、コンテンツ スニッフィングを禁止するように指示されます。 「nosniff」を追加するために必要なパラメータは 1 つだけです。

このヘッダーを宣伝する方法を見てみましょう。

アパッチ

これを行うには、httpd.conf ファイルに次の行を追加します。

 Header set X-Content-Type-Options nosniff 

構成をアクティブにするために、Apache Web サーバーを再起動することを忘れないでください。

Nginx

nginx.conf ファイルのサーバー ブロックの下に次の行を追加します。

 add_header X-Content-Type-Options nosniff; 

いつものように、結果を確認するには Nginx を再起動する必要があります。

マイクロソフトIIS

IIS を開き、HTTP 応答ヘッダーに移動します。

「追加」をクリックし、名前と値を入力します。

[OK] をクリックし、IIS を再起動して結果を確認します。

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

Web ページの HTTP 応答にコンテンツ セキュリティ ポリシー (CSP) ヘッダーを実装することで、XSS、クリックジャッキング、 コード インジェクション 攻撃を防止します。 CSP は 、Web サイトに読み込むことが許可されているコンテンツを読み込むようにブラウザに指示します。

すべての ブラウザが CSP をサポートしているわけではない ため、実装する前に確認する必要があります。 CSP ヘッダーを実現するには 3 つの方法があります。

• コンテンツ セキュリティ ポリシー – レベル 2/1.0
• X-Content-Security-Policy – 非推奨
• X-Webkit-CSP – 非推奨

非推奨のものをまだ使用している場合は、最新のものにアップグレードすることを検討してください。

CSP を実装するには複数のパラメータがあり、アイデアについては OWASP を参照してください。ただし、最もよく使用される 2 つのパラメーターを見てみましょう。

パラメータ値	意味
デフォルトの送信元	定義されたソースからすべてをロードします
スクリプトソース	定義されたソースからのスクリプトのみをロードします

次の例は、さまざまな Web サーバーに同じオリジンからすべてをロードする例です。

アパッチ

httpd.conf ファイルに次の内容を追加し、Web サーバーを再起動して有効にします。

 Header set Content-Security-Policy "default-src 'self';" 

Nginx

nginx.conf ファイルのserverブロックに以下を追加します。

 add_header Content-Security-Policy "default-src 'self';"; 

マイクロソフトIIS

IIS マネージャーで各サイトの HTTP 応答ヘッダーに移動し、次の内容を追加します。

CSP を使用してフレーム祖先を実装するには、これを確認してください。これは、X-Frame-Options の上級バージョンです。

X-許可されたクロスドメインポリシー

PDF、Flash などの Adob​​e 製品を使用していますか?

このヘッダーを実装すると、クロスドメイン経由でリクエストを処理する方法をブラウザーに指示できます。このヘッダーを実装すると、他のドメインからのサイトのアセットの読み込みが制限され、リソースの乱用が回避されます。

いくつかのオプションが利用可能です。

価値	説明
なし	ポリシーは許可されません
マスターのみ	マスターポリシーのみを許可する
全て	すべてが許可されています
コンテンツのみ	特定の種類のコンテンツのみを許可します。例 – XML
FTP のみによる	FTP サーバーにのみ適用可能

アパッチ

どのポリシーも許可したくない場合。

 Header set X-Permitted-Cross-Domain-Policies "none"

次のようなヘッダーが表示されるはずです。

Nginx

そして、マスターのみを実装する必要があるとします。その後、 nginx.conf の server ブロックの下に次のコードを追加します。

 add_header X-Permitted-Cross-Domain-Policies master-only;

そして結果。

リファラーポリシー

サイトのリファラーポリシーを制御したいと考えていますか?プライバシーとセキュリティには一定の利点があります。ただし、すべてのオプションがすべてのブラウザでサポートされているわけではないため、実装する前に要件を確認してください。

Referrer-Policy は次の構文をサポートします。

価値	説明
非参照者	参照元情報はリクエストとともに送信されません。
ダウングレード時にリファラーなし	リファラーが HTTP から HTTP、HTTPS から HTTPS と同じプロトコルに送信されるデフォルト設定。
安全でない URL	完全な URL がリクエストとともに送信されます。
同起源	リファラーは同じオリジンサイトに対してのみ送信されます。
厳密な起源	プロトコルが HTTPS の場合にのみ送信します
クロスオリジンの場合の厳密なオリジン	完全な URL は HTTPS などの厳密なプロトコルを介して送信されます
起源	すべてのリクエストでオリジン URL を送信します
原点とクロス原点	同じオリジンでフル URL を送信します。ただし、それ以外の場合はオリジン URL のみを送信します。

アパッチ

リファラーなしを設定したい場合は、以下を追加できます。

 Header set Referrer-Policy "no-referrer"

再起動後、応答ヘッダーに が含まれているはずです。

Nginx

同じオリジンを実装する必要があるため、次のコードを追加する必要があるとします。

 add_header Referrer-Policy same-origin;

設定が完了すると、以下の結果が得られるはずです。

予想CT

まだ実験段階にある新しいヘッダーは、証明書の透過性 (CT) のために Web サーバーとの接続を検証するようにブラウザーに指示します。 Google によるこのプロジェクトは、SSL/TLS 証明書システムのいくつかの欠陥を修正することを目的としています。

Expect-CT ヘッダーには次の 3 つの変数が使用できます。

価値	説明
最大年齢	ブラウザがポリシーをキャッシュする期間を秒単位で指定します。
強制する	ポリシーを強制するためのオプションのディレクティブ。
レポートウリ	有効な証明書の透過性が受信されなかった場合に、指定された URL にレポートを送信するブラウザ。

アパッチ

このポリシー、レポート、キャッシュを 12 時間適用したい場合は、次の行を追加する必要があるとします。

 Header set Expect-CT 'enforce, max-age=43200, report-uri="https://somedomain.com/report"'

そして、結果がこれです。

Nginx

1 時間レポートしてキャッシュしたい場合はどうすればよいでしょうか?

 add_header Expect-CT 'max-age=60, report-uri="https://mydomain.com/report"';

出力は次のようになります。

アクセス許可ポリシー

以前は機能ポリシーとして知られていましたが、機能が強化されたアクセス許可ポリシーに名前が変更されました。 これを 確認すると、機能ポリシーからアクセス許可ポリシーへの大きな変更点を理解できます。

アクセス許可ポリシーを使用すると、位置情報、全画面表示、スピーカー、USB、自動再生、スピーカー、マイク、支払い、バッテリー ステータスなどのブラウザー機能を制御して、Web アプリケーション内で有効または無効にすることができます。このポリシーを実装すると、サーバーがクライアント (ブラウザー) に Web アプリケーションの機能に従うように指示できるようになります。

アパッチ

フルスクリーン機能を無効にする必要があるとします。そのためには、使用する Apache HTTP サーバーの種類に応じて httpd.conf または apache2.conf ファイルに次の内容を追加できます。

 Header always set Permissions-Policy "fullscreen 'none' "

複数の機能を 1 行に追加してみてはいかがでしょうか?

それも可能です！

 Header always set Permissions-Policy "fullscreen 'none'; microphone 'none'"

Apache HTTP を再起動して結果を確認します。

 HTTP/1.1 200 OK
Date: Thu, 29 Apr 2021 06:40:43 GMT
Server: Apache/2.4.37 (centos)
Permissions-Policy: fullscreen 'none'; microphone 'none'
Last-Modified: Thu, 29 Apr 2021 06:40:41 GMT
ETag: "3-5c116c620a6f1"
Accept-Ranges: bytes
Content-Length: 3
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

上記のコードは、ブラウザーに全画面表示とマイクを無効にするように指示します。

ホワイトリストを空のままにして機能を完全に無効にすることもできます。

たとえば、次のコードを追加して地理位置情報機能を無効にすることができます。

 Header always set Permissions-Policy "geolocation=()"

ブラウザ上では以下のように出力されます。

 HTTP/1.1 200 OK
Date: Thu, 29 Apr 2021 06:44:19 GMT
Server: Apache/2.4.37 (centos)
Permissions-Policy: geolocation=()
Last-Modified: Thu, 29 Apr 2021 06:40:41 GMT
ETag: "3-5c116c620a6f1"
Accept-Ranges: bytes
Content-Length: 3
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Nginx

別の例を見てみましょう – 振動機能を無効にしてみましょう。

 add_header Permissions-Policy "vibrate 'none';";

または、地理位置情報、カメラ、スピーカーを無効にします。

 add_header Permissions-Policy "geolocation 'none'; camera 'none'; speaker 'none';";

Nginx を再起動した後の出力は次のとおりです。

 HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 29 Apr 2021 06:48:35 GMT
Content-Type: text/html
Content-Length: 4057
Last-Modified: Mon, 07 Oct 2019 21:16:24 GMT
Connection: keep-alive
ETag: "5d9bab28-fd9"
Permissions-Policy: geolocation 'none'; camera 'none'; speaker 'none';
Accept-Ranges: bytes

すべての Nginx 設定は、 nginx.conf または使用するカスタム ファイルの http ブロックの下に置かれます。

サイトデータのクリア

名前から推測できるように、Clear-Site-Data ヘッダーの実装は、キャッシュ、ストレージ、Cookie などの閲覧データをクリアするようにクライアントに指示する優れた方法です。これにより、Web サイトのデータをブラウザーに保存する方法をより詳細に制御できるようになります。

アパッチ

元のキャッシュをクリアしたい場合は、以下を追加できます。

 Header always set Clear-Site-Data "cache"

以下のようなHTTPレスポンスが出力されます。

 HTTP/1.1 200 OK
Date: Thu, 29 Apr 2021 07:52:14 GMT
Server: Apache/2.4.37 (centos)
Clear-Site-Data: cache
Last-Modified: Thu, 29 Apr 2021 06:40:41 GMT
ETag: "3-5c116c620a6f1"
Accept-Ranges: bytes
Content-Length: 3
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

または、すべてをクリアします。

 Header always set Clear-Site-Data "*"

Nginx

Cookie をクリアするように Nginx を設定しましょう。

 add_header Clear-Site-Data "cookies";

そして、以下の出力が表示されます。

 HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 29 Apr 2021 07:55:58 GMT
Content-Type: text/html
Content-Length: 4057
Last-Modified: Mon, 07 Oct 2019 21:16:24 GMT
Connection: keep-alive
ETag: "5d9bab28-fd9"
Clear-Site-Data: cookies
Accept-Ranges: bytes

結論

Web サイトのセキュリティを確保するのは困難ですが、上記のヘッダーを実装することでセキュリティ層が追加されることを願っています。ビジネスサイトを運営している場合は、オンラインビジネスを保護するためにSUCURIのようなクラウドWAFの使用を検討することもできます。 SUCURIの良いところは、セキュリティとパフォーマンスの両方を提供していることです。

SUCURI WAF を使用する場合は、[ファイアウォール] >> [セキュリティ] タブに追加のヘッダー セクションがあります。