Moraxyc's Rhapsody

セキュリティレスポンスヘッダーを設定することで、クライアントが侵入されるのを効果的に防ぐことができます。

URL の検出#

Security Headers

Mozilla Observatory

イントロダクションと設定#

HTTP 厳格輸送セキュリティ(HSTS)#

http は平文で送信され、完全に暗号化されていないため、誰でも送信データからブラウザとサーバー間のすべての内容を取得できます。したがって、https で使用される TLS 暗号化は非常に評価されます。しかし、特別に指定しない限り、https を使用することはなく、ドメイン名にアクセスするたびに、最初にサーバーに http リクエストを送信し、次にサーバーがブラウザにリダイレクトを送信し、ブラウザが https にアップグレードします。

HSTS はこの問題を解決する方法です。

ブラウザが https サイトから送信されたStrict-Transport-Securityヘッダーを受信すると、ブラウザは指定された時間に https アクセスを実行します。ブラウザが再度そのサイトにアクセスし、指定された時間が経過していない場合、ブラウザは HTTP リクエストを送信せず、直接 https 接続を使用します。これにより、SSL 剥離などの攻撃から未だに https 接続にアップグレードされていないものを防ぎます。

e.g.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

このヘッダーには 3 つのパラメータがあります：max-age=63072000、includeSubDomains、preload。

• max-age=は HTTPS 接続を維持する時間を示し、後に秒数が続きます。例えば、max-age=31536000は 1 年間 https 接続のみを使用することを意味します。
• includeSubDomainsは、そのドメインのすべてのサブドメインが https アクセスを使用することを示します。

HSTS は良いですが、最初の接続は常に http です。もし長い間狙っているスクリプトキディ浸透専門家が常に動きを見ている場合、どうすればよいでしょう？

preloadパラメータはこの問題を解決するために使用されます。ブラウザはChromeまたはFirefoxのプリロードリストから、直接 https 接続を使用すべきサイトを取得します。このリストはHSTSpreloadで積極的に提出できます。

このリストはchrome://net-internals/#hstsでローカル Chrome 上で確認および編集できます。

X-Frame-Options#

CSP パラメータの使用を推奨
Content-Security-Policyレスポンスヘッダーには、frame-ancestorsパラメータがあり、X-Frame-Optionsレスポンスヘッダーを完全に置き換え、さらに多くの機能を持っています。

X-Frame-Options HTTP レスポンスヘッダーは、ブラウザに対してページが<frame>、<iframe>、<embed>、または<object>内で表示されるかどうかを指示するために使用されます。サイトは、他のサイトに埋め込まれないようにすることで、クリックジャッキング攻撃を回避できます。

e.g.

X-Frame-Options: SAMEORIGIN

このヘッダーには 2 つのパラメータ、SAMEORIGINとDENYがあります。

• SAMEORIGINは、そのページが同じオリジンのドメインのみがフレームを表示することを許可します。
• DENYは、すべてのフレームを完全に許可しません。

X-Content-Type-Options#

このヘッダーの主な目的は、クライアントに対してレスポンスヘッダーContent-Typeで指定されたファイルのMIMEタイプを厳守するよう要求することです。そうでなければ、ブラウザはMIME-sniffingを使用して返されたファイルの内容を推測し、実行します。

このヘッダーが設定されていない場合、画像や他のメディアファイルに隠れているjavascriptやcssが攻撃者によってシステムに侵入される可能性があります。

e.g.

X-Content-Type-Options: nosniff

このヘッダーにはnosniffという 1 つのパラメータがあり、クライアントに通知します。

• nosniffは、MIME タイプに一致しないリクエストを防ぎます。

X-XSS-Protection#

ブラウザの互換性
現在、Safari ブラウザのみがサポートしています。
このヘッダーは完全に構成可能な CSP ヘッダーに置き換えることができます。

このヘッダーの役割はその名前の通りで、ブラウザが XSS 攻撃を防ぐためのものであり、どの規格や草案にも属していません。

e.g.

X-XSS-Protection: 1; mode=block

このヘッダーには 4 つのパラメータがあります_{引用元：Mdn}

• 0 XSS フィルタリングを無効にします。

• 1 XSS フィルタリングを有効にします。クロスサイトスクリプト攻撃が検出されると、ブラウザはページをクリアします（安全でない部分を削除します）。

• 1;mode=block XSS フィルタリングを有効にします。攻撃が検出されると、ブラウザはページをクリアせず、ページの読み込みを防ぎます。

• 1; report=<reporting-URI>は Chrome 4-77 バージョンのみがサポートします。このパラメータは XSS フィルタリングを有効にします。クロスサイトスクリプト攻撃が検出されると、ブラウザはページをクリアし、CSP report-uri の機能を使用して違反報告を送信します。

Permissions Policy#

このヘッダーは、ページがアクセスできるブラウザ機能を制御するために使用され、サイトが自らの権限範囲を事前に定義することができます。

e.g.

Permissions-Policy: geolocation=()

このヘッダーには多くのパラメータがあり、パラメータの構文は<directive>=<allowlist>です。前半部分は権限を示し、後半部分は許可されるホワイトリストを示します。

ホワイトリストには 3 つの値があります：

• *: 現在のページおよびページ内に表示されているすべてのコンテンツがその機能を使用することを許可します。
• (): その機能の使用を許可しません。
• (self "https://example.org"): このパラメータはワイルドカードを使用することを許可し、各許可されたサイトをスペースで区切ります。selfはこのページを示します。

コンテンツセキュリティポリシー（CSP）#

このヘッダーは、どのコンテンツがこのページで使用され、実行されることを許可されているかを定義します。

CSP の設定は非常に複雑で、詳細については阮一峰先生のブログContent Security Policy 入門教程を参照してください。

私は輪を再発明したくありません決して書くのが面倒だからではありません

CSP ヘッダーを適切に設定した後、Google が提供するCSP Evaluatorを使用して、自分の CSP ポリシーが強力かどうかを確認できます。

スコア#

最初の 2 つの検出 URL は、レスポンスヘッダーを検出するために使用できます。Securityheaders の検出は Mozilla のものほど厳格ではなく、一般的に A + に達することができれば、セキュリティレスポンスヘッダーの設定がほぼ完了していることを示します。