Cookieとセッションを操る
Applicationタブを使ってCookieの値を書き換え、権限チェックを迂回するCTFの基本テクニックを体験します。「role=guest」を「role=admin」に変えて管理者エリアへ侵入しましょう。
📋 目次
🍪 CookieとSessionの仕組み｜HTTPはなぜ「記憶」できないのか
ステートレスなHTTPがどうやってログイン状態を保持するか
HTTP は本来「記憶がない」プロトコル
Webの通信プロトコル「HTTP」は、リクエストとレスポンスを1回ずつやり取りしたら、その内容をすべて忘れる「ステートレス（無状態）」な設計になっています。つまり、ページを読み込むたびに「あなたは誰ですか？」とゼロから問い直すのが本来の動作です。ログイン状態を維持するには、この「記憶のなさ」を補う仕組みが必要で、それがCookieとセッションです。
Cookieとは、サーバーがブラウザへ「次回以降これを持ってきてください」と渡す小さなデータのことです。ブラウザはCookieを保存しておき、同じサイトへアクセスするたびに自動的にリクエストヘッダーへ添付して送信します。これにより、「ログイン済みである」「カートに商品が入っている」などの状態を継続できます。
セッションとは、ログインした瞬間にサーバーが生成する「利用者の情報をまとめた記録」です。サーバー側に保存されたセッションレコードに対し、ブラウザは「セッションID」というランダムな文字列をCookieとして受け取り、以降のリクエストにそのIDを添付することで「自分が誰か」を証明します。
CTFでよく登場する脆弱なCookieパターン
セキュリティが甘いWebアプリでは、role=guest・isAdmin=false・user=aliceのように、権限や認証情報そのものをCookieに直接保存しているケースがあります。ブラウザ側で書き換えられるCookieをサーバーがそのまま信頼するのは、非常に危険な設計です。CTFでは、このような「クライアント任せの権限管理」を攻略する問題が多く出題されます。
💻 ApplicationタブでCookieを確認・編集する
開発者ツールのApplicationタブがCookie操作の起点
F12（またはCmd+Option+I）で開発者ツールを開き、「Application」タブをクリックすると、左サイドバーに「Storage」セクションが表示されます。その中の「Cookies」を展開し、現在閲覧中のドメインをクリックすると、そのページに保存されたすべてのCookieが一覧で表示されます。
Cookieの値を編集するには、ValueフィールドをダブルクリックしてEnterで確定するだけです。画像ではctf_roleのValueがguestになっています。これをadminに書き換えてページを操作すると、サーバーやJavaScriptは「管理者」として認識してしまう可能性があります。
Applicationタブへのショートカット
F12 で開発者ツールを開いた後、Networkタブ・Elementsタブが先に表示された場合は、タブ一覧を右にスクロールすると「Application」が見つかります。見当たらない場合は>>ボタン（オーバーフローメニュー）を開いてください。
🛡️ Cookieのセキュリティ属性を読み解く
HttpOnly・Secure・SameSiteが守るもの
ApplicationタブのCookie一覧には、単なる名前と値だけでなく、セキュリティに関わる属性列があります。CTFの問題を解くうえでも、これらの属性が「書き換え可能かどうか」「JavaScriptから読めるかどうか」を左右するため、理解しておくことが重要です。
| 属性名 | 設定効果 | CTFでの意味 |
|---|---|---|
| HttpOnly | JavaScriptからdocument.cookieでアクセスできない | ⛔ チェック付きのCookieはJS読み取り不可。Applicationタブ（サーバーからの受信レコード）では見えるがJSでは取れない |
| Secure | HTTPS接続時のみサーバーへ送信される | HTTPSが必須。HTTP接続でのCTFでは意味を持たないことも |
| SameSite=Strict | クロスサイトリクエストへのCookie添付を禁止 | CSRF攻撃を防ぐが、CTF問題では設定の有無で攻撃手法が変わる |
| SameSite=Lax | 外部サイトからのGETリクエストには送信、POSTには送らない | デフォルト値（Chrome）。Laxでも一部CSRF攻撃が通る |
| Expires / Max-Age | Cookieの有効期限を指定 | Sessionの場合はブラウザ終了時に削除。永続Cookieはファイルに保存 |
| Domain / Path | Cookieを送信するドメインとパスを限定 | サブドメイン共有などの設定ミスがCTFのヒントになることも |
HttpOnly が付いていてもApplicationタブでは見える
HttpOnlyはJavaScriptによる読み取りをブロックしますが、開発者ツールのApplicationタブはブラウザの内部機能なので制限を受けません。CTFでは「document.cookieでは取れないが、Applicationタブを開いたら一覧に出てきた」という状況が普通に起こります。ツールを使いこなすことがCTF攻略のカギです。
🧩 CTFで使う「Cookie書き換え」テクニック3選
実戦で役立つ手順をマスターする
Applicationタブで直接Valueを書き換える（最速・最簡単）
前セクションで紹介した通り、ApplicationタブでCookieのValueフィールドをダブルクリック→新しい値を入力→Enterで確定するだけです。書き換え後にページを再操作（ボタンを押す・ページを更新する）することで、新しいCookie値がサーバーまたはJavaScriptへ送られます。最も手軽で、CTFの多くの問題で通用します。
Consoleからdocument.cookieで書き換える（HttpOnly以外）
開発者ツールの「Console」タブで、document.cookie = 'ctf_role=admin; path=/';と入力するとCookieを追加・上書きできます。この方法はHttpOnlyが付いていないCookieのみ有効で、プログラム的に操作できるメリットがあります。複数のCookieを一度に変えたいときや、スクリプトで自動化したいときに活躍します。
Base64エンコードされたCookieを解読・改ざんする
Cookieの値がeyJyb2xlIjoiZ3Vlc3QifQ==のようなBase64形式になっている場合、Consoleでatob('eyJyb2xlIjoiZ3Vlc3QifQ==')と入力するとデコードできます。中身が{"role":"guest"}だとわかれば、btoa('{"role":"admin"}')でエンコードし直してCookieに設定します。CTFではJSON+Base64の組み合わせが頻出パターンです。
ヒント：削除して新規追加もできる
Applicationタブで既存のCookieを右クリックして「Delete」、またはCookie行を選択してDeleteキーを押すと削除できます。その後、Consoleからdocument.cookie = 'key=newvalue; path=/'で新しいCookieを追加するという操作も覚えておくと便利です。
🧩 5分CTFチャレンジ：role=adminに書き換えろ！
Applicationタブを開いてCookieを操作する
このページには ctf_role というCookieが自動的に設定されており、初期値は guest です。下の「管理者エリアへ入る」ボタンを押すと、JavaScriptが現在の ctf_role の値を確認します。guest のままでは弾かれますが、admin に書き換えると管理者フラグが現れます。
チャレンジの手順
① F12 で開発者ツールを開く → ② Applicationタブをクリック → ③ 左パネル「Cookies」を展開→ドメインをクリック → ④ ctf_role の Value（guest）をダブルクリック → ⑤ admin と入力してEnterで確定 → ⑥ 下の「管理者エリアへ入る」ボタンを押す → ⑦ フラグが表示されたら入力フォームへ！
現在の ctf_role Cookie の値：
（読み込み中…）
👑 管理者エリアへようこそ！
フラグを見つけました：
CTF{S3SS10N_H1J4CK3R}
⚠️ 本物のサイトではサーバー側でセッション検証を行うため、Cookie書き換えだけでは突破できません。これはCTF学習用のシナリオです。
上で管理者エリアに表示されたフラグを入力してください。フォーマットは CTF{...} です。
F12 で開発者ツールを開き、「Application」タブを選択してください。左サイドバーの「Storage」→「Cookies」→ドメイン名の順にクリックすると、Cookie一覧が表示されます。
ctf_role 行の「Value」列をダブルクリックすると編集できます。guest を消して admin と入力し、Enterキーを押してから「管理者エリアへ入る」ボタンを押してみてください。
📝 まとめ＋FAQ＋次回予告
今回のポイントを振り返ろう
第7話では、CookieとセッションのHTTP通信における役割を学び、ApplicationタブでCookie値を直接書き換える方法を体験しました。権限情報をCookieにそのまま保存して検証不足のサーバーは、今回のような「role=admin書き換え」攻撃に脆弱です。この脆弱性はWeb CTFの定番問題であり、実際の開発でも注意すべきポイントです。
・HTTPはステートレス → CookieがWebの「記憶」を担う
・セッションIDをCookieで管理し、サーバー側でセッションレコードを照合するのが正しい設計
・Applicationタブ → Cookies → Valueをダブルクリックで編集できる
・HttpOnly属性付きCookieはJSから読めないがApplicationタブでは見える
・権限情報をCookie値として直接保存・信頼するサイトはCTFの格好のターゲット
Q. Cookieを書き換えたらサーバーにバレませんか？
サーバー側でセッションIDを使った検証を行っているサイトでは「不正なセッション」として弾かれます。しかし、Cookieの値そのものを権限判断に使い、セッション検証をしていない脆弱なサイトは書き換えが通ってしまいます。CTFではあえてそのような設計のサーバーを標的にします。
Q. HttpOnlyが付いているCookieはどうやって攻撃しますか？
JavaScriptでは読み書きできませんが、Applicationタブで値を確認・編集することは可能です。また、より高度な攻撃ではXSS（クロスサイトスクリプティング）の脆弱性を組み合わせてCookieを盗む手法もありますが、それは中〜上級編のトピックです。
Q. Cookieを削除したらどうなりますか？
セッションCookieを削除するとログアウト状態になります。永続Cookieを削除すると次回アクセス時に再設定されます。CTFでは「Cookieを意図的に空にして動作確認する」ことも問題解法のヒントになることがあります。
Q. SameSite=Strictが設定されていると何が変わりますか？
外部サイトから誘導されたリクエストにはCookieが添付されなくなります。これによりCSRF（クロスサイトリクエストフォージェリ）攻撃を防げます。ただし、CookieのValueを直接編集する今回のテクニックには影響しません。SameSiteはリクエストの送信元を制限するものであり、同一ドメイン内での操作には適用されないためです。
ソースコードを読んでみよう
ページのHTMLソースやJavaScriptファイルを読み解き、隠されたコメントや難読化された変数名の中からフラグを探します。
📚 参考情報
- MDN Web Docs「HTTP Cookie」（Mozilla）
- RFC 6265 — HTTP State Management Mechanism（Cookie仕様書）
- OWASP「Session Management Cheat Sheet」
コメント