鍵をかけても「窓」が開いていたら？セッションクッキーを守る3つの防犯ルール
こんにちは。現場で泥臭いインシデント対応を繰り返していると、「完璧なシステムなんてない」という現実を突きつけられます。でも、だからこそ「最低限ここだけは守ろう」という鉄則が、被害を最小限に食い止める命綱になるんです。
今日は、Webアプリケーションの心臓部である「セッションクッキー」を守るための、絶対に外せない3つの設定についてお話しします。
—
1. なぜ「セッションクッキー」が狙われるの？
まず、セッションクッキーを「家の鍵」だと思ってください。
一度ログインすると、ブラウザは「この人は本人です！」という証明書（セッションID）をクッキーとして持ち歩きます。この鍵があれば、毎回パスワードを入力しなくてもサイトを利用できますよね。
しかし、泥棒（攻撃者）は、この鍵を盗もうと虎視眈々と狙っています。
- XSS（クロスサイトスクリプティング）： サイトに隠された悪意あるコードで、ブラウザから鍵をこっそりコピーされる。
- CSRF（クロスサイトリクエストフォージェリ）： あなたになりすまして、勝手に送金や投稿をされる。
これらを防ぐための「最強の防犯セット」が、クッキーの3つの属性です。
—
2. 泥棒から鍵を守る「3つの防犯設定」
① HttpOnly：鍵を「見えない箱」に入れる
通常、JavaScriptというプログラムを使うと、ブラウザ内のクッキーを読み取ることができます。でも、もしサイトに脆弱性があって攻撃者がJavaScriptを埋め込めたら、クッキーは丸見えになってしまいます。
- HttpOnly属性をつけると、JavaScriptからクッキーへのアクセスが物理的に不可能になります。
- 「鍵はブラウザの裏側の金庫にあるから、プログラムからは触れないよ」という状態にするわけです。
② Secure：鍵の「通り道」を厳重にする
インターネット上の通信は、何も対策しないと「盗み見」が可能です。Secure属性がないと、暗号化されていないWi-Fiなどでもクッキーが送信されてしまいます。
- Secure属性をつけると、HTTPS（暗号化された通信）の場合のみクッキーを送信するようになります。
- これは「暗号化された安全なルートを通る時しか、鍵を持ち出しませんよ」という約束事です。
③ SameSite：鍵を「他の家」に持ち出させない
これが最近のトレンドであり、最も重要な防犯策です。
CSRF攻撃は、悪意のある別のサイトから、あなたのブラウザ経由で「本人になりすまして」リクエストを送りつけます。
- SameSite=Strict：同じサイト内からしか鍵を送信しません（一番安全）。
- SameSite=Lax：リンクを辿ってきた時などは許可しますが、それ以外は鍵を送信しません（現在のデフォルト推奨）。
—
3. 実践！設定サンプル
では、実際にどう設定すればいいのか。多くのWebサーバーやフレームワークでは、レスポンスヘッダーの Set-Cookie で制御します。
サーバーがブラウザに「この鍵を使ってね」と渡す時の設定例
Set-Cookie: session_id=abc123xyz; Secure; HttpOnly; SameSite=Lax
各設定の意味（復習）：
session_id=abc123xyz: あなたのセッションIDです。Secure: HTTPS通信の時だけ送る！HttpOnly: JavaScriptからは絶対に読み取らせない！SameSite=Lax: 外部サイトからの怪しいリクエストには鍵を渡さない！
—
4. 一歩ずつ、現場でできることから
「うちのサイトは古いから…」と諦める必要はありません。まずは開発環境や、次にリリースする機能からこれらの属性を付与してみてください。
最近のブラウザは非常に優秀で、SameSite が設定されていないと「警告」を出してくれることもあります。まずはブラウザの「開発者ツール（F12キー）」を開いて、Application（またはStorage）タブから、自分のサイトのクッキーがどうなっているか覗いてみてください。
「Secure」や「HttpOnly」のチェックボックスが外れていませんか？
セキュリティは、一度にすべてを完璧にする必要はありません。今日、この記事を読んで確認したその一歩が、何百人、何千人ものユーザーを犯罪から守ることにつながります。
まずは自分のサイトの「鍵」を確認することから、一緒に始めていきましょう！
コメント