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

JavaScriptに鍵を預けない!HttpOnly属性でセッションクッキーを泥棒から守る方法

皆さん、こんにちは!サイバーセキュリティの世界へようこそ。今回は、Webアプリケーション開発でとっても大事な「セッションクッキー」のお話です。特に、新人IT担当者さんや、これからセキュリティを学び始める開発者の皆さんにとって、これは「なるほど!」と思っていただけるはず。

「HttpOnly属性?何それ、難しそう…」なんて思わないでくださいね。実は、これ、私たちの身近な「家の鍵」や「泥棒」に例えると、すごく分かりやすいんです。一緒に、このHttpOnly属性がどういう仕組みで、なぜ私たちのセッションクッキーを守ってくれるのか、じっくり紐解いていきましょう。

そもそもセッションクッキーって、何者?

まず、セッションクッキーの役割を思い出してみましょう。

例えるなら、あなたがお店に入るときに、お店の人が「この人、さっきも来たお客さんだな」って分かるように、腕に「一時的なリストバンド」を巻いてくれるイメージです。このリストバンド(セッションクッキー)があるおかげで、お店の人はあなたを識別し、ログイン状態を維持したり、カートの中身を覚えておいてくれたりするわけです。

このリストバンド、つまりセッションクッキーは、Webサーバーがあなたのブラウザに発行する、いわば「あなた専用のチケット」のようなものです。このチケットがあれば、いちいち「私は〇〇です」って毎回名乗らなくても、スムーズにサービスを利用できるんですよね。

泥棒は、この「リストバンド」を狙っている!

さて、ここで「泥棒」の登場です。サイバー攻撃者、つまり泥棒は、この「あなた専用のチケット」、つまりセッションクッキーをどうにかして手に入れようとします。なぜなら、もし泥棒があなたのセッションクッキーを手に入れたら…?

まるで、あなたが持っている「お店のリストバンド」を泥棒が奪って、そのままお店に入って、あなたのふりをして好き放題するようなものです!あなたの名前で買い物をされたり、個人情報を見られたり…想像するだけでゾッとしますよね。

XSS攻撃:泥棒の「手口」の一つ

セッションクッキーを盗む手口はいくつかありますが、今回は特に「クロスサイトスクリプティング(XSS)」という攻撃に焦点を当てます。

XSS攻撃というのは、Webサイトに悪意のあるスクリプト(JavaScriptなど)を仕掛けられてしまう攻撃です。もし、あなたがその仕掛けられたWebサイトをブラウザで開いてしまうと、その悪意のあるスクリプトがあなたのブラウザ上で実行されてしまうんです。

この悪意のあるスクリプトは、まるで「泥棒があなたの家の鍵穴を覗き込み、中から鍵を盗もうとする」ようなものです。具体的には、あなたのブラウザが持っているセッションクッキーを、JavaScriptを使って盗み取ろうとします。

HttpOnly属性:JavaScriptには「触らせない!」というお約束

ここで、ついにHttpOnly属性の出番です!

HttpOnly属性というのは、クッキーを発行する際に「このクッキーにはJavaScriptからはアクセスさせないでくださいね!」という、ブラウザへの「お約束」や「指示」のようなものです。

例えるなら、家の鍵を、玄関のドアノブにぶら下げておかないで、ちゃんと「鍵束」に入れて、しかもその鍵束は「鍵のかかった引き出し」にしまっておく、というようなイメージです。

HttpOnly属性が付いているクッキーは、ブラウザが「これはJavaScriptには触らせちゃダメなやつだ」と理解してくれます。だから、もし万が一、WebサイトにXSS攻撃が仕掛けられて、悪意のあるJavaScriptが実行されたとしても、そのJavaScriptはHttpOnly属性が付いたセッションクッキーにアクセスできなくなるんです。

つまり、泥棒が窓から手を伸ばして鍵を盗もうとしても、鍵が「鍵のかかった引き出し」の中にしまってあって、JavaScriptという「泥棒の手」はそこまで届かない、というわけです。これは、セッションクッキーが盗まれるリスクを、ぐっと減らしてくれる、とっても強力な防御策なんです。

HttpOnly属性の設定方法

では、具体的にどうやってこのHttpOnly属性を設定するのでしょうか?これは、Webサーバー側でクッキーを発行する際に、HTTPヘッダーに Set-Cookie という形で指定します。

例:PHPでの設定

PHPでセッションクッキーを発行する場合、session.cookie_httponly という設定を php.ini で 1 にするのが一般的です。

php.ini の設定例:

; セッションクッキーにHttpOnly属性を付与します。
; 0: 付与しない
; 1: 付与する (推奨)
session.cookie_httponly = 1

; セキュア属性も同時に設定すると、HTTPS接続時のみクッキーが送信されます。
; 0: 付与しない
; 1: 付与する (HTTPS利用時のみ推奨)
session.cookie_secure = 1

もし、個別のクッキーを Set-Cookie ヘッダーで直接設定する場合は、以下のように HttpOnly を追加します。

例:Node.js (Express) での設定

Express.js を使っている場合、express-session のようなセッション管理ミドルウェアで設定することが多いです。

const express = require(‘express’);
const session = require(‘express-session’);
const app = express();

app.use(session({
secret: ‘your_secret_key’, // セッションIDを署名するための秘密鍵
resave: false,
saveUninitialized: true,
cookie: {
httpOnly: true, // ★ここで HttpOnly を true に設定します!
secure: process.env.NODE_ENV === ‘production’, // 本番環境では HTTPS のみで送信
maxAge: 1000 60 60 24 // 24時間
}
}));

// … その他のミドルウェアやルート設定

例:Webサーバー (Nginx) での設定

Webサーバー側でクッキーを直接操作することは少ないかもしれませんが、もし必要であれば、Nginxの設定でも proxy_cookie_flags などを使って設定できる場合があります。ただし、アプリケーション側で適切に設定するのが一般的です。

セキュア属性(Secure Attribute)との合わせ技も忘れずに!

HttpOnly属性と並んで、もう一つ大切なのが「セキュア属性(Secure Attribute)」です。これは、「このクッキーはHTTPS(暗号化された通信)で通信しているときだけ、ブラウザに送信してくださいね」という指示です。

例えるなら、「鍵は、普段は鍵のかかった引き出しにしまっておくけど、雨の日(HTTPS通信時)だけ、特別に鍵束ごと持ち歩く」といったイメージでしょうか。

HttpOnly属性とセキュア属性を両方設定することで、セッションクッキーのセキュリティは格段に向上します。

  • HttpOnly: JavaScriptからのクッキーへのアクセスを防ぐ(泥棒が内側から盗むのを防ぐ)
  • Secure: HTTPS通信時のみクッキーを送信する(泥棒が通信を盗聴してクッキーを奪うのを防ぐ)

この二つは、まさに「泥棒対策の二枚看板」と言えるでしょう。

まとめ: HttpOnly属性で、より安全なWebアプリケーションを

今回は、HttpOnly属性について、身近な例えを交えながら解説しました。

  • セッションクッキーは、Webサービス利用時の「あなた専用のチケット」。
  • XSS攻撃は、そのチケットを盗もうとする「泥棒の手口」の一つ。
  • HttpOnly属性は、JavaScriptにセッションクッキーを触らせないようにする「鍵のかかった引き出し」のようなもの。

このHttpOnly属性の設定は、一度覚えてしまえば、開発やインフラ構築の際に「いつもこれを入れる」という習慣になります。新人IT担当者さんも、一般開発者さんも、ぜひ今日からこのHttpOnly属性を意識して、より安全なWebアプリケーション開発・運用を目指しましょう!

セキュリティ対策は、一つ一つ地道に、でも着実に進めていくことが大切です。分からないことがあれば、またいつでも聞いてくださいね!一緒に、サイバー攻撃から私たちのサービスを守っていきましょう!

コメント

タイトルとURLをコピーしました