今回はCookieではなく「IDの番号」が攻撃の起点になります。あなた自身のIDから始めて、ID番号を変えていくことで他人の情報に到達し、さらにその情報から次のIDを発見するという、2段階の「チェーン」を体験します。CTF実践編のテーマである「複数の技術を繋ぐ」を、今回は同じ1つの技術（IDOR）を2回繰り返して繋ぐ、というシンプルな形で体感していただきます。

IDOR（Insecure Direct Object Reference）とは、ユーザーが指定したID（番号やファイル名など）に対応するデータを、サーバーが「このIDを要求した人に見る権限があるか」を確認せずそのまま返してしまう脆弱性です。/profile?user_id=1001のようなURLで、1001を1002に変えるだけで他人のプロフィールが見られてしまう、というのが典型例です。

たとえば「請求書PDFをダウンロードするURLにinvoice_id=1001という番号がそのまま使われていて、番号を1つずつ変えるだけで他人の請求書（氏名・住所・金額などの個人情報を含む）が次々にダウンロードできてしまった」というパターンは、実際のバグバウンティ報告でも繰り返し見られる典型例です。請求書・予約情報・チャット履歴など、「自分のものだけ見えるはず」のデータほど、IDORの被害が深刻になりやすい領域だと言えます。

すべてのID設計が同じように危険というわけではありません。ID自体が「予測しやすいか」によって、IDORの悪用しやすさが大きく変わります。

架空の社内ポータル「やさい商事プロフィール検索」では、user_idを指定すると誰でもプロフィールを閲覧できてしまいます（権限チェックがありません）。あなたのIDは1001です。他のIDを試して、手がかりを探してください。

IDORが今も頻発する理由の1つは、権限チェックを入れなくても機能テストでは正常に動いてしまうことです。開発者自身のテストアカウントでログインして確認する限り、自分のデータしか触らないため、権限チェック漏れに気づきにくいのです。バグが見つかるのは、悪意のある第三者（またはCTFプレイヤー）がIDを書き換えて初めて、というケースが少なくありません。

今回のチャレンジは、実は2種類の権限昇格を1つのチェーンに組み込んでいます。ID1037の同僚プロフィールを見る行為は「同じ立場の他人のデータを覗く」水平権限昇格（Horizontal Privilege Escalation）です。一方、そこで得た手がかりからID8842の管理者プロフィールに到達する行為は「より高い権限のデータに到達する」垂直権限昇格（Vertical Privilege Escalation）にあたります。実際の攻撃チェーンでも、まず水平方向に複数のアカウントを覗いて手がかりを集め、最後に垂直方向へ一気に踏み込む、という流れがよく見られます。

次回は、今回見つけた「管理者かどうか」を判定する仕組みそのものを狙います。Cookieの値でもIDの番号でもなく、JWT（JSON Web Token）という署名付きのトークンを偽造し、サーバーに「自分は管理者だ」と信じさせる技術に挑戦します。

第2話では、IDの番号を変えるだけで他人の情報に到達できてしまうIDORを体験しました。1段階のIDORだけでなく、見つけた情報から次のIDを発見し、さらに深い情報へと進む「チェーン」の感覚をつかんでいただけたなら成功です。