【入門編】CookieのHttpOnly属性によるセッションハイジャック防止 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは。セキュリティの世界で泥沼のようなインシデント対応を幾度となく経験してきた、現場叩き上げのエンジニアです。

今日は、Web開発の世界で「基本中の基本」と言われながら、実は多くの現場でポロポロと穴が開いている「CookieのHttpOnly属性」について、お話ししようと思います。

「そんなの知ってるよ、設定すればいいんでしょ？」と思ったあなた。なぜその設定が重要なのか、なぜそれがないと家の中まで泥棒を招き入れてしまうのか、その「リアルなメカニズム」を一緒に紐解いていきましょう。

—

まずは想像してみてください。Webサイトにログインするということは、そのサイトから「あなたは本人ですよ」という証明書（セッションID）を渡されることと同じです。

通常、ブラウザはこの証明書（Cookie）を大切に保管し、サイトにアクセスするたびに「私です！」と提示してくれます。これが、ログイン状態を維持する仕組みです。

ここで恐ろしいのが、「JavaScript（Webページ上で動くプログラム）」も、デフォルトではこのCookieを自由に読み取れてしまうという仕様です。

もし、あなたのサイトの検索窓やコメント欄に、悪意のある攻撃者が「スクリプト（命令文）」を忍び込ませたとします。これがいわゆる「XSS攻撃」です。

攻撃者は、あなたのサイトに訪れたユーザーのブラウザ上で、こっそりとこんな命令を実行させます。

> 「ブラウザの保存領域にあるCookieを全部コピーして、私のサーバーに送れ！」

こうなると、ユーザーが必死に守っていた「身分証明書」は、一瞬で泥棒の手に渡ります。泥棒は盗んだIDを使って、ユーザーになりすましてサイトにログインします。これを「セッションハイジャック」と呼びます。

—

ここで登場するのが、今回の主役「HttpOnly属性」です。

これはCookieに対して、「JavaScriptからは絶対に見るな！」という制限をかける、いわば「鍵のかかった金庫」のようなものです。

この属性を付けておくと、仮にサイトにXSSの脆弱性があって、攻撃者が「Cookieを見せろ！」と命令を出しても、ブラウザは「ダメです。これはJavaScriptからは触れない決まりなんです」と拒否してくれます。

泥棒が窓（XSS）から侵入に成功しても、肝心の「身分証明書（Cookie）」は頑丈な金庫の中にしまわれているため、持ち出すことができないのです。

—

では、実際にどうやって設定するのか見ていきましょう。難しいことはありません。「サーバーからブラウザへCookieを送る際に、おまじないを一つ足すだけ」です。

サーバーがCookieを発行する際のヘッダー設定は、以下のようになります。

サーバーがブラウザにCookieを渡す時のヘッダー
Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; SameSite=Lax

PHPであれば、session_start() を呼ぶ前に設定するだけでOKです。

0,
‘path’ => ‘/’,
‘domain’ => ‘your-site.com’,
‘secure’ => true, // HTTPS環境なら必須！
‘httponly’ => true, // これが今回の重要設定
‘samesite’ => ‘Lax’
]);

session_start(); // これでセッションが保護された状態で開始されます

—

ここまで読んで「HttpOnlyを設定すれば完璧！」と思った方もいるかもしれません。しかし、現場の泥臭い教訓として一つだけ伝えておきます。

「HttpOnlyは、あくまで最後の砦の一つに過ぎません。」

XSSそのものを防ぐ努力（入力値のサニタイズや、出力時のエスケープ処理）を怠れば、たとえCookieが盗まれなくても、サイトの改ざんや偽のログイン画面への誘導など、別の被害が生まれます。

セキュリティは、「穴を一つずつ丁寧に埋めていく作業」です。

まずは今日、あなたが管理しているWebアプリのブラウザ開発者ツールを開いてみてください。「Application」タブの「Cookies」を開き、自サイトのCookieに「HttpOnly」のチェックが入っているか確認してみましょう。

もし入っていなければ、それがあなたのシステムにおける「最初の改善点」です。一歩ずつ、安全な開発の道を歩んでいきましょうね！