IDOR — 持ち主を確かめずに返す穴

穴のある場所を読む

shanai-memo では、メモは /api/notes/:id で取れます。vulnerable/server.mjs の該当部分です。

const apiMatch = /^\/api\/notes\/(\d+)$/.exec(pathname);
if (apiMatch) {
  const id = Number(apiMatch[1]);
  const note = notes.find((n) => n.id === id);
  ...
  res.end(JSON.stringify(note)); // ← 持ち主チェックが無い(穴)
}

id で引いたメモを、誰が要求しているかを一切見ずにそのまま返しています。メモ #1 は alice、#2 は bob、#3 は carol のもの。alice でログインしていても、/api/notes/2 を叩けば bob のメモが返ります。

攻める

ブラウザで「alice でログイン」した状態を思い出してください。alice が持っているのはメモ #1 だけです。ところが——

node exploit/idor.mjs

[IDOR] 成立: alice のセッションで bob のメモ #2 を読めました(持ち主チェックが無い)

手で確かめると、alice のセッションクッキーを付けて #2 を要求するだけで、中身が返ります。

curl -s -H "cookie: session=alice" "http://127.0.0.1:4599/api/notes/2"

{"id":2,"owner":"bob","title":"bob の個人メモ(架空)","body":"架空の私的メモ。持ち主は bob。alice には見えてはいけない内容。"}

"owner":"bob" のメモが、alice に返ってしまいました。ログインはしているのに、そのデータを見る権利があるかは誰も確かめていません。認証(誰であるか)と認可(何をしてよいか)は別物で、ここで欠けているのは認可です。

直す

修正の芯は、ログイン利用者と、データの持ち主が一致するときだけ返すこと。/api/notes を次のように変えます(currentUser はすでにこのファイルにある関数です)。

const apiMatch = /^\/api\/notes\/(\d+)$/.exec(pathname);
if (apiMatch) {
  const me = currentUser(req);
  const id = Number(apiMatch[1]);
  const note = notes.find((n) => n.id === id);
  if (!note) {
    res.writeHead(404, { 'content-type': 'application/json' });
    res.end(JSON.stringify({ error: 'not found' }));
    return;
  }
  if (!me || note.owner !== me) {
    res.writeHead(403, { 'content-type': 'application/json; charset=utf-8' });
    res.end(JSON.stringify({ error: 'forbidden' }));
    return;
  }
  res.writeHead(200, { 'content-type': 'application/json; charset=utf-8' });
  res.end(JSON.stringify(note));
  return;
}

同じ考え方は、ブラウザ用の /notes/:id にも要ります(こちらも持ち主照合を足します)。認可は、データを返すすべての入口に必要です。

再検証する

サーバを再起動して、もう一度攻めます。

node exploit/idor.mjs

[IDOR] 防御されています: HTTP 403(他人のメモは返らない)

curl でも、alice からの #2 は 403 になりました。

HTTP/1.1 403 Forbidden
{"error":"forbidden"}

自分のメモ(alice なら #1)はこれまで通り読めて、他人のメモだけが返らない——認可が効いた状態です。

持ち帰る一言

認証と認可は別。IDで引いたら、要求者のものかを毎回サーバで確かめる。 クライアントに「他人のボタンを隠す」だけでは守りになりません。URLは誰でも書き換えられるからです。守りは必ずサーバ側に置きます。