HTTPSは「入れただけ」では守れない。HSTSでSSLストリッピングを完全に封殺する
現場でコードレビューをしていると、未だに「HTTPS化しているから大丈夫」と胸を張るエンジニアに出くわす。だが、断言しよう。その認識こそが、攻撃者に付け入る最大のスキを与えている。
今日は、XSSのようなアプリケーション層の脆弱性もさることながら、通信経路そのものを乗っ取る「SSLストリッピング」という悪夢を、HSTS（HTTP Strict Transport Security）でどう防ぐかについて、実務的な話をしよう。
なぜ、HTTPSだけでは不十分なのか？
多くのWebサイトは、ユーザーが http:// でアクセスしてきた際に 301 Moved Permanently を返して https:// へリダイレクトさせている。しかし、この「最初のHTTPアクセス」こそが脆弱性だ。
攻撃者は、公共のWi-Fiなどで中間者（MitM）となり、このリダイレクトを握りつぶす。ユーザーをHTTPのまま接続させ続け、暗号化されていない通信を盗聴・改ざんする。これが「SSLストリッピング攻撃」だ。
ユーザーのブラウザに「このサイトは一生HTTPSでしか通信しない」と叩き込むこと。それがHSTSの役割であり、セキュリティ要件としては「必須」と言い切っていい。
HSTSの防御メカニズムと実装
HSTSは、HTTPレスポンスヘッダーに特定の値を設定するだけで機能する。
Nginxでの設定例
Nginxで運用しているなら、サーバーブロックに以下の設定を加える。
HSTSヘッダーの設定
includeSubDomains: サブドメインも含めて全域でHTTPSを強制
preload: ブラウザのHSTSプリロードリストへの登録を許可
max-age=63072000: 2年間（約1年単位が推奨）はHTTPでの接続を一切許可しない
add_header Strict-Transport-Security “max-age=63072000; includeSubDomains; preload” always;
PHPでの設定例
もしインフラ側で制御できない事情があるなら、アプリケーションの入り口（index.php 等）でヘッダーを送出する。
注意すべき「落とし穴」
ここで多くのエンジニアが犯すミスが2つある。
1. max-age が短すぎる: テスト目的で max-age=3600（1時間）に設定し、そのまま放置するケース。これでは攻撃者に猶予を与えているに等しい。本番環境では最低でも1年（31536000）以上を設定すべきだ。
2. 証明書の有効期限切れ: HSTSを設定した状態で証明書が切れると、ユーザーは「警告を無視して接続」することすらできなくなる（ブラウザがアクセスを拒否する）。運用サイドにとっては死活問題だ。証明書の自動更新（Certbot等）は必須のセットとなる。
「最初の一回」さえ守る：HSTSプリロード
HSTSを有効にしても、ユーザーが「初めてそのサイトにアクセスする瞬間」には、まだヘッダーを受け取っていないため、依然としてSSLストリッピングの脅威に晒されている。
これを解決するのが「HSTSプリロードリスト」だ。ブラウザ自体に「このドメインはHTTPS必須」とハードコードさせる仕組みである。
1. 上記の設定を適用し、preload ディレクティブを含める。
2. [hstspreload.org](https://hstspreload.org/) にアクセスし、自分のドメインを送信する。
3. 要件を満たしていれば、数週間から数ヶ月で主要ブラウザのソースコードにあなたのドメインが刻まれる。
最後に：セキュリティは「多層」で考える
HSTSはあくまで「通信の出口」を守る盾だ。もしアプリケーション側にXSS脆弱性が放置されていれば、HTTPS通信の中でセッションCookieが盗まれる事態は避けられない。
- HSTS: 通信経路をHTTPSに固定し、中間者攻撃を防ぐ。
- CSP (Content Security Policy): XSSを緩和し、不正なスクリプトの実行を制限する。
- Secure/HttpOnly属性: Cookieを守り、セッションハイジャックを防ぐ。
これらを組み合わせ、初めて「堅牢なシステム」と言える。教科書の記述を鵜呑みにせず、なぜそのヘッダーが必要なのかを理解し、泥臭く実装し続けること。それがプロのエンジニアの流儀だ。
もし今、あなたの管理しているサイトで Strict-Transport-Security ヘッダーが送られていないのなら、今すぐ設定ファイルを開いてほしい。それが今日、君たちがすべき「最も実務的なセキュリティ対策」だ。
コメント