鍵をかけても「合鍵」が盗まれる？WebのセッションハイジャックとHttpOnlyの重要性
こんにちは。セキュリティの現場で日々、防御の最前線に立っている者です。
今日は、開発者やIT担当者なら必ず一度は耳にする「HttpOnly」という魔法のような属性について、少し掘り下げてお話ししましょう。「セキュリティ対策」と聞くと難しく感じますが、実は私たちの身の回りの防犯と同じくらいシンプルで、かつ人間味のある考え方なんですよ。
一歩ずつ、一緒に紐解いていきましょう。
—
1. 家の鍵と「セッションID」の関係
皆さんがWebサイトにログインするとき、サイト側は皆さんに「あなたはログイン中のユーザーですよ」という証明書を発行します。これが「セッションID（Cookie）」です。
これを、「玄関を開けるための合鍵」だと想像してみてください。
一度ログインすると、ページを移動するたびに「合鍵（Cookie）」を提示することで、いちいちパスワードを入力し直さなくても済みますよね。でも、もしこの「合鍵」を泥棒にコピーされてしまったらどうなるでしょう？
泥棒は、皆さんのフリをして堂々と玄関から入り込み、個人情報を盗んだり、勝手に操作したりできてしまいます。これが「セッションハイジャック」です。
2. なぜ「合鍵」は盗まれるのか？（XSSの脅威）
ここで登場するのが、XSS（クロスサイト・スクリプティング）という攻撃です。
もし皆さんが開発しているWebサイトに少しでも「隙（脆弱性）」があると、攻撃者はそこに「悪意のあるJavaScript」を仕込むことができます。このプログラムは、皆さんのブラウザ上でこっそり動き、こう囁きます。
「ねえ、君が持っているその『合鍵（Cookie）』を見せてよ」
通常、JavaScriptはブラウザ上のデータに自由にアクセスできる権限を持っています。つまり、対策をしていないCookieは、「誰でも自由に覗き見できる状態の鍵」なのです。一度XSSが成功すれば、攻撃者は皆さんのセッションをいとも簡単に盗み出せてしまいます。
3. HttpOnlyという「頑丈な防犯ケース」
ここで登場するのが「HttpOnly（エッチティーティーピー・オンリー）」です。
これは、Cookieを発行する際に付与できる「属性」の一つです。これを設定すると、ブラウザに対して以下のような指示が出ます。
「このCookieは、ブラウザの通信（HTTPリクエスト）には使っていいけど、JavaScriptからは絶対に触らせないで！」
つまり、JavaScriptという「泥棒」がやってきても、ブラウザが「ごめんね、これはHttpOnlyだから中身は見せられないよ」とガードしてくれるようになるんです。これこそが、セッションハイジャックを防ぐための最も基本的で、かつ最も強力な防犯対策なのです。
—
4. 実践：HttpOnlyを設定してみよう
では、実際にどうやって設定するのでしょうか。難しく考える必要はありません。サーバーからCookieを送る際、ヘッダーに「HttpOnly」という文字列を添えるだけです。
HTTPレスポンスヘッダーの例
サーバーがブラウザにCookieを渡すときは、以下のような形になります。
Set-Cookie: session_id=abc123xyz789; Secure; HttpOnly; SameSite=Strict
- HttpOnly: JavaScriptからのアクセスを禁止します。
- Secure: 通信を暗号化（HTTPS）しないとCookieを送信しないようにします（これも必須！）。
- SameSite=Strict: 外部サイトからの不正なリクエストを弾く、現代の防犯の要です。
プログラムコードでの設定例（Node.js/Expressの場合）
もし皆さんがWebアプリケーションを書いているなら、設定はもっと簡単です。
// ExpressでのCookie設定例
res.cookie(‘session_id’, ‘abc123xyz789’, {
httpOnly: true, // 【重要】JavaScriptからの読み取りをブロック
secure: true, // 【重要】HTTPS通信時のみ送信
sameSite: ‘strict’ // 【重要】クロスサイトリクエストを抑制
});
—
最後に：完璧な防御なんて存在しないけれど
「HttpOnlyにしておけば、もう安心ですよね？」
そう言いたいところですが、セキュリティの世界に「100%」はありません。HttpOnlyはあくまで「XSSが起きたとしても、セッションIDだけは守り抜く」ための強力な壁です。
しかし、大元の脆弱性（XSSそのもの）を放置していては、別の被害（情報の改ざんやなりすまし操作など）が起きてしまいます。
「JavaScriptに触らせないこと（HttpOnly）」と「そもそも悪意のあるスクリプトを混入させないこと（入力値のバリデーションや出力のエスケープ）」。この両輪を回すことが、私たちエンジニアが守るべきプロフェッショナリズムではないでしょうか。
まずは、皆さんのサイトのCookieがHttpOnlyになっているか、ブラウザの開発者ツールを開いて確認してみてください。「Name」や「Value」の横に「HttpOnly」のチェックボックスが入っていれば、その鍵はしっかりと防犯ケースに守られていますよ。
次回の記事では、この「XSSそのものをどうやって防ぐか」について、現場の泥臭い知見を交えて解説しますね。またお会いしましょう！
コメント