「HTTPS対応済み」という慢心が招く惨劇：HSTSで「最初の1秒」を死守せよ
現場でインシデント対応をしていると、よく耳にするのが「HTTPS化は完了しています」という言葉だ。だが、本当にそうだろうか？
多くのエンジニアが犯す致命的な勘違いは、「URLの先頭を `https://` に書き換えること」だけでセキュリティが完結していると思っている点だ。ユーザーがアドレスバーに直接 `example.com` と打ち込んだとき、あるいはカフェのフリーWi-Fi経由で最初にアクセスしたとき、ブラウザはまず「HTTP（平文）」で通信を試みる。
この「HTTPSにリダイレクトされるまでのわずかな隙間」こそ、攻撃者が待ち構える狩場だ。今回は、この盲点を突く中間者攻撃（MitM）を防ぐための、HSTS（HTTP Strict Transport Security）の極意を伝授する。
—
1. なぜ「リダイレクト」だけでは不十分なのか？
攻撃者の常套手段に「SSLストリッピング」がある。ユーザーがHTTPでアクセスしようとした際、攻撃者がその通信を傍受し、「サーバー側はHTTPSをサポートしていないフリ」を演じて、ユーザーとサーバーの間を平文で中継する手法だ。
この攻撃を受けたユーザーは、自分が安全なHTTPSサイトを見ているつもりで、パスワードやセッションIDを平文で送信してしまう。このとき、サーバー側でいくら「HTTPからHTTPSへリダイレクト」する設定を書いていても、最初のHTTP通信が乗っ取られてしまえば意味がない。
これを防ぐ唯一の対抗策がHSTSだ。HSTSは、「ブラウザに対して、今後一定期間は絶対にHTTPS以外で接続してはならない」と強制的に覚え込ませる命令である。
—
2. HSTSの黄金設定：Nginxでの実装例
HSTSを導入する際、最も手っ取り早く、かつ確実なのはWebサーバー（Nginx等）でヘッダーを付与することだ。以下の設定を `nginx.conf` に追加してほしい。
365日間(31536000秒) HTTPS接続を強制する設定
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” always;
注意: alwaysを付けることで、エラーページやリダイレクト時にもヘッダーが確実に付与される
パラメータの解説：
- `max-age=31536000`: 1年間、ブラウザにこの設定を記憶させる。短期間で設定すると攻撃の窓が開くので、まずは1年で設定し、安定稼働後に伸ばすのが鉄則だ。
- `includeSubDomains`: サブドメイン（`api.example.com` 等）も含めて強制する。これを忘れるとサブドメインが攻撃の穴になる。
- `preload`: HSTS Preload List（後述）に登録するための必須オプション。
—
3. 「初回接続」の壁を突破する：HSTS Preload List
HSTSには一つだけ弱点がある。「そのサイトに一度でもHTTPSでアクセスしてヘッダーを受け取るまでは、HSTSが有効にならない」という点だ。
この「初回のアクセス」を保護するために作られたのが、[HSTS Preload List](https://hstspreload.org/) だ。ブラウザ（Chrome, Firefox, Safari等）のソースコード自体に「このドメインは絶対にHTTPSしか許さない」というリストを埋め込む手法である。これに登録すれば、ユーザーの初回アクセス時であっても、ブラウザが勝手にHTTPSでの接続を試みてくれる。
登録前のチェックリスト
登録は簡単だが、一度登録すると解除には数週間かかるため、慎重に行う必要がある。
1. 全サブドメインでHTTPSが有効か？
2. 証明書は適切に設定されているか？
3. `preload` ヘッダーを付けて、最低でも数ヶ月運用し、問題がないことを確認したか？
—
4. アプリケーションコード側での実装（参考）
Webサーバーで制御できない環境（サーバーレスや一部のPaaS）の場合、アプリケーション側でヘッダーを制御する必要がある。
Python (Flask) の場合
@app.after_request
def apply_hsts(response):
# すべてのレスポンスにHSTSヘッダーを付与
response.headers[“Strict-Transport-Security”] = “max-age=31536000; includeSubDomains; preload”
return response
PHP の場合
—
最後に：セキュリティは「設定して終わり」ではない
HSTSを導入したからといって、アプリケーション側の脆弱性が消えるわけではない。だが、「暗号化されていない通信を物理的に排除する」という土台作りは、インシデントレスポンスにおいて最も費用対効果の高い防御策の一つだ。
読者の皆さんが抱える環境で、もし `Strict-Transport-Security` ヘッダーが送信されていないサイトがあるなら、今すぐ設定を検討してほしい。「なんとなくHTTPSにしている」という状態から、「HTTPS以外を許さない」という強固な姿勢へシフトすることこそが、プロのエンジニアの矜持だ。
現場からは以上だ。また次の戦場で会おう。
コメント