HTTPSは「導入すれば終わり」ではない。HSTSが守る「暗号化のラストワンマイル」
現場で多くのインシデントを見てきたが、未だに「SSL証明書を入れたから安全だ」と勘違いしているエンジニアが後を絶たない。残念ながら、それは大きな間違いだ。
HTTPSを導入しても、ユーザーが最初にサイトへアクセスする際、ブラウザは「まずHTTPで接続を試みる」ことがある。この「最初の数ミリ秒」の隙を狙うのがSSLストリッピング攻撃（中間者攻撃の一種）だ。攻撃者はユーザーとサーバーの間に割って入り、HTTP通信を強制して暗号化を無効化する。ユーザーが気づかないうちに、セッションIDやパスワードを平文で盗み取る、恐ろしい手口だ。
これを防ぐ唯一の防御策が HSTS (HTTP Strict Transport Security) である。今回は、理論だけでなく、明日から即戦力として使える「鉄壁の防御設定」を叩き込む。
—
1. なぜ「SSLストリッピング」は防げないのか？
攻撃者の手口は巧妙だ。ユーザーが http://example.com にアクセスした瞬間、攻撃者はサーバーになりすましてリダイレクトを横取りする。
1. ユーザー: http://example.com にアクセス。
2. 攻撃者: ユーザーとの通信はHTTPで維持しつつ、背後で本物のサーバーとはHTTPSで通信する。
3. 結果: ユーザーは「HTTPSで通信している」と思い込んでいるが、実際には暗号化されていない通信が攻撃者のPCを通過している。
HSTSは、この「最初のHTTPリクエスト」すらブラウザ側で禁止し、強制的にHTTPSへ置き換える仕組みだ。一度HSTSヘッダーを受け取ったブラウザは、次回以降そのドメインに対してHTTPでのアクセスを一切許容しなくなる。
—
2. 実務で即戦力となるHSTS設定ファイル
HSTSを有効にするには、サーバーの応答ヘッダーに Strict-Transport-Security を付与するだけだ。だが、設定値を間違えるとサイトが壊滅するので注意してほしい。
Nginxでの設定例
Nginxであれば、server ブロックに以下を記述する。
HSTS設定
max-age: 1年(31536000秒)
includeSubDomains: サブドメインも保護対象に含める
preload: HSTSプリロードリストへの登録を許可する
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” always;
PHPでの設定例（フレームワーク共通）
もしNginxの設定が難しい場合は、アプリケーション側でヘッダーを注入する。
—
3. 「プリロード（Preload）」こそが最終防衛線
上記のヘッダーを設定しても、実は「初回アクセス時」にはまだ無防備だ。ユーザーがそのサイトを初めて訪れた瞬間には、まだヘッダーを受け取っていないからだ。
この「初回の脆弱性」すら潰すのが HSTS Preload List だ。
ブラウザ（Chrome, Firefox, Safari等）の中に「このサイトは絶対にHTTPS以外認めない」というリストをハードコーディングしてもらう仕組みである。
1. 上記の設定を済ませる（preload パラメータが必須）。
2. [hstspreload.org](https://hstspreload.org/) にアクセスし、ドメインを申請する。
3. 一度登録されると、世界中のブラウザが「そのサイトへはHTTP接続を一切行わない」ことを保証する。
—
4. 現場でやってはいけない「やってしまった！」事例
後輩のレビューでよく指摘する、絶対に避けるべきミスを共有しておく。
max-ageが短すぎる:max-age=0はHSTSの無効化を意味する。テスト時以外は最低でも1年（31536000）を設定すること。- サブドメインを考慮しない:
includeSubDomainsを付け忘れると、api.example.comなどのサブドメインが攻撃の入り口になる。 - 証明書の期限切れ: HSTSを有効にすると、証明書エラーが発生した際にユーザーは「例外を無視して進む」ことができなくなる。証明書が切れるとサイトが完全に閉鎖状態になるため、証明書の自動更新（Certbot等）は必須要件だ。
—
最後に：防御は「設定」ではなく「文化」
HSTSは、アプリケーションのコードを1行も変えずに導入できる最高にコスパの良いセキュリティ対策だ。しかし、セキュリティにおいて「これだけで完璧」というものはない。
HSTSは「HTTPSの徹底」という土台を作るためのもの。その上で、Cookieに Secure 属性を付与し、SameSite 属性でCSRFを防ぐ。一つひとつの設定が重なり合って初めて、ユーザーの信頼を守る強固な城壁ができる。
今日、この設定をデプロイした瞬間から、君たちのサービスは「攻撃者に隙を見せない」プロフェッショナルな設計へと一歩前進するはずだ。運用に不安があれば、いつでもまた相談してくれ。
コメント