Skip to main content

HSTS - HTTP Strict Transport Security

About 2 min read

HSTS (HTTP Strict Transport Security) とは、 Web サーバーがブラウザに対して 「今後このドメインには HTTPS でのみ接続せよ」と指示するセキュリティ機構です。 2012 年に RFC 6797 として標準化されました。SSL/TLS による暗号化通信を 強制することで、中間者攻撃の 一種である SSL ストリッピング攻撃を防止します。 HTTP レスポンスヘッダーに 1 行追加するだけで導入でき、コスト対効果が極めて高いセキュリティ対策です。

SSL ストリッピング攻撃とは

SSL ストリッピングは、 2009 年に Moxie Marlinspike が Black Hat DC で発表した攻撃手法です。 ユーザーが http://example.com にアクセスすると、通常はサーバーがhttps://example.com へリダイレクトします。攻撃者はこの最初の HTTP 通信を 傍受し、ユーザーとの間は HTTP のまま通信を維持しつつ、サーバーとの間は HTTPS で通信します。 ユーザーから見ると通常通りサイトが表示されますが、通信内容は攻撃者に筒抜けです。

SSL ストリッピングの流れ:
1. ユーザーが http://example.com にアクセス
2. 攻撃者が HTTP リクエストを傍受
3. 攻撃者がサーバーに HTTPS で接続 (正規の通信を中継)
4. ユーザーには HTTP のままレスポンスを返す
5. ユーザーの入力 (パスワード、カード番号等) が平文で攻撃者に渡る
HSTS が有効な場合: ブラウザが HTTP リクエストを送信する前に内部で HTTPS に変換するため、 ステップ 1 の時点で攻撃が成立しない

HSTS ヘッダーのディレクティブ

ディレクティブ説明推奨値
max-ageブラウザが HSTS ポリシーを記憶する秒数。この期間中、ブラウザは HTTP アクセスを自動的に HTTPS に変換する31536000 (1 年間)
includeSubDomainsサブドメインにも HSTS を適用する。 api.example.com や cdn.example.com も HTTPS が強制される設定推奨
preloadHSTS Preload List への登録意思を示す。ブラウザに事前組み込みされ、初回アクセスから保護されるPreload List 登録時に必須

完全な HSTS ヘッダーの例:

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

HSTS Preload List

通常の HSTS には「初回アクセス問題」があります。ブラウザが HSTS ヘッダーを受け取るのは 最初の HTTPS 接続時であり、その前の HTTP アクセスは保護されません。 HSTS Preload List はこの問題を解決する仕組みです。

HSTS ヘッダーに preload を追加hstspreload.org で登録申請Chromium チームが審査ブラウザのソースコードに組み込み初回アクセスから HTTPS 強制

Preload List に登録されると、 Chrome、 Firefox、 Safari、 Edge など主要ブラウザが 初回アクセスから HTTPS を強制します。ただし、登録の解除には数ヶ月かかるため、 HTTPS 対応が不完全な状態で登録するとサイトにアクセスできなくなるリスクがあります。

段階的な導入手順

HSTS の導入は段階的に進めるのが安全です。いきなり max-age=31536000 を 設定すると、 HTTPS の設定ミスがあった場合に長期間サイトにアクセスできなくなります。

Step 1 (5 分)
max-age=300

まず 5 分間で動作確認。問題があっても 5 分待てば解消する。

Step 2 (1 週間)
max-age=604800

1 週間に延長。サブドメインを含む全ページが HTTPS で正常動作することを確認。

Step 3 (1 ヶ月)
max-age=2592000; includeSubDomains

サブドメインも含めて 1 ヶ月。証明書の自動更新が正常に動作することを確認。

Step 4 (1 年)
max-age=31536000; includeSubDomains; preload

最終形。 Preload List への登録を検討する段階。

CSP との併用

HSTS は通信経路の暗号化を強制する仕組みであり、ページ内のコンテンツ制御は行いません。CSP (Content Security Policy) と 併用することで、通信経路とコンテンツの両面からセキュリティを強化できます。 CSP の upgrade-insecure-requests ディレクティブは、ページ内の HTTP リソース参照を自動的に HTTPS に変換する機能であり、 HSTS と補完関係にあります。通信の暗号化を 徹底するには、 HSTS と CSP の両方を設定することが推奨されます。

ブラウザパスワードの安全性スタートアップのセキュリティチェックリスト公衆 Wi-Fi のセキュリティも あわせて参照してください。web security books on Amazonで HTTPS の運用ベストプラクティスを学ぶことを推奨します。

Related Terms

Was this article helpful?

XHatena