2026.05.01

【セッション・Cookie編】奪われたら全部終わる身分証の守り方｜CTF思考フレームワーク #08

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　認証・セッション編　#08 / 公開中 10記事　→　シリーズ一覧を見る →

セッションやCookieは「ログイン状態の身分証」みたいなもの。一度奪われたら、攻撃者は被害者そのものとしてサイトを使えてしまいます。今回はその「身分証」がどう発行されて、どこから漏れて、どう守ればいいかを整理します🍪

今回はセッション・Cookie・JWTの3点セットで「身分証の脆弱化」を見ていきます。

難易度：★★☆（中級）

このシリーズは「攻撃者の思考をなぞる」ことが目的。手を動かさなくても読み物として理解できるレベルです👍

セッションって地味だけど、ここがガバガバだと他で頑張っても全部水の泡なんだ💦

この記事の難易度

難易度：★★☆（やさしめ）　／　所要：8〜10分　／　前提：#01〜#07の認証系

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
⚖️ 大事なお約束
📚 次に読みたい
🧪 自分で検証してみる

👀 観察フェーズ：まず何を見る？

まずはCookieとレスポンスヘッダをじっくり眺めるのが基本！何が見える？

Cookie属性が緩いとXSS経由で持っていかれ、SameSiteが甘いとCSRFが刺さり、JWTがalg=noneを許せば署名なしで通る。地味ですが大事なチェックです。

ブラウザのDevTools → Application → CookiesでCookie属性(Secure/HttpOnly/SameSite)を確認。Network タブでSet-Cookieヘッダの全文も見ましょう👀

Set-CookieにHttpOnlyがない？JWTのalgがHS256？気になるサインはたくさんあるね🍪

🤔 仮説フェーズ：攻撃者は何を考える？

観察した事実から、攻撃者目線で4つの仮説を立てるよ。

ここから攻撃者の仮説を見ていきましょう。

🍪 仮説①：Cookie属性が緩くてXSSで盗まれる

HttpOnlyが無ければJavaScriptからCookieが読まれてしまいます。XSSが1つあれば即セッション窃取につながります。

🔓 仮説②：SameSiteが甘くてCSRFが通る

SameSite=NoneかつSecureでないと、外部サイトから勝手にリクエストが飛んでもCookieが付いて行きます。

🔑 仮説③：JWTのalg=noneを許してる

JWTのheaderを{"alg":"none"}に書き換えても通る実装が稀にあります。署名検証を完全スキップできるので壊滅的。

🎯 仮説④：ログインしてもセッションIDが変わらない

セッション固定化攻撃の温床。攻撃者が用意したIDをそのまま被害者に使わせて、ログイン後の状態を共有できてしまいます。

Cookie/JWTは「クライアント側に置く以上、いつか触られる」前提で設計する必要があります。

クライアントに置いてる時点で「いつか触られる」前提で守らないとダメなんだね😨

🔬 検証フェーズ：どうやって確かめる？

仮説が立ったら自分の検証環境で確かめます。実環境はNG🚫

仮説を実際に検証していく流れを追ってみましょう。

Burp SuiteでCookie書き換え→挙動観察、jwt.ioでJWTデコード→改ざんトライ、っていう順かな？

⚔️ 攻撃フェーズ：実際の手口

代表的なセッション攻撃はこの3つ。

ここからは実戦シナリオを見ていきます。

① セッションハイジャック

XSSや通信傍受でセッションIDを盗み、そのまま被害者になりすましてログイン状態を引き継ぐ。最も古典的かつ強力。

② JWT改ざん（alg=none / 弱い秘密鍵）

alg=noneを許す実装や、HS256で推測可能な秘密鍵を使っていると、payloadを書き換えて管理者権限に昇格できる。

③ セッション固定化

攻撃者が事前に発行したセッションIDを被害者に使わせ、ログイン後の認証済み状態を奪う。ログイン時にセッションIDを再生成しないと防げない。

CTF{rotate_session_id_on_login_always}

基本は「クライアント側に置いた瞬間から信頼してはいけない」。ログイン時のセッション再生成、JWT署名の厳格検証、Cookie属性の徹底が3点セットです。

🛡️ 防御フェーズ：どう守る？

守る側はこの3レイヤーを全部やるのが鉄則だよ🛡️

守る側の必須対策はこの3つです。

🍪 Cookie属性を厳格化

Secure + HttpOnly + SameSite=Lax(またはStrict)を必ず付ける。これだけでXSS窃取とCSRFの大半を遮断できる。

🔑 JWTの署名検証を厳格に

alg=noneを絶対に許さない。秘密鍵は十分長くランダムに。可能ならRS256など非対称暗号で公開鍵検証する。

🔄 ログイン時にセッションID再生成

認証成功直後に必ずセッションIDをローテート。これで固定化攻撃は無力化される。

「Cookie3点セット + JWT署名厳格 + ID再生成」の3つだけでも世界が変わるんだね！

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

⚠️ よくある落とし穴

現場でよく見かけるミスはこんな感じです。

JWTを「改ざん不能」と過信する。payloadは平文でデコード可能。
LocalStorageに認証トークンを置いてしまう（XSSで一発で抜かれる）。
ログイン前後でセッションIDが同じまま。
ログアウトをクライアント側のCookie削除だけで済ませる（サーバ側に残る）。
SameSite=Noneを安易に設定して、CSRFを許す。
JWTライブラリの「alg=none許可」設定を放置する。

🧰 ツール早見表

ここで使うツールを早見表にまとめました。

ツール	用途	ひと言
jwt.io	JWTデコード・改ざん	まず最初に触る定番
CyberChef	エンコード・暗号操作全般	Base64・JWT・XOR…なんでも来い
Burp Suite	Cookie操作・リプレイ	セッション系全般の主役
EditThisCookie / Cookie Editor	ブラウザ拡張でCookie編集	手早く属性を確認・改ざん