認証・認可の脆弱性:ログインとIDOR
BOLAとは APIのオブジェクト単位の認可漏れ
この回でやること
IDORのAPI版の呼び名がBOLAです。画面を介さずAPIを直接叩く形では欠陥が見つけにくく塞ぎ漏らしやすい理由と、資源ごとに持ち主を確かめる直し方を扱います。
- 読む 約 7 分
- 最後にクイズ 1 問
このレッスンで学ぶこと
BOLAは「壊れたオブジェクトレベル認可」の略で、持ち主の確認漏れをAPIを直接叩く側から見たときの呼び名です。この回はIDORと同じ欠陥なのに、API側のほうが塞ぎ漏らしやすい理由を扱います。
読み終えると、自分のAPIで持ち主の確認を通すべき口を、どこまで数えればよいかが分かります。
同じ穴の、API側の呼び名
BOLAは、APIが1件ずつの資源、いわゆるオブジェクトを返すときに、その資源を要求者が触ってよいかを確かめない欠陥です。/api/orders/1043のような資源を名指しする口で、IDを差し替えて他人のものが取れる。中身はIDORと同じで、APIの用語として呼ぶときにBOLAと言います。呼び名が2つあるのは、Web画面の脆弱性の一覧とAPIの脆弱性の一覧が別々に整理されてきた歴史のためで、指しているものは変わりません。
画面が無い分、見つけにくい
画面のあるIDORは、まだ探しやすいほうです。導線が目に見えるからです。BOLAが厄介なのは、画面に出ない口まで直接叩けることにあります。
プレーンテキスト
GET /api/orders/1043 画面から使う口
GET /api/orders/1043/items 明細を返す別の口
GET /api/users/57/addresses 住所を返す口
DELETE /api/orders/1043 画面には無い操作画面は、利用者に使わせたい導線しか見せません。ところがAPIには、画面が一度も呼ばない資源や操作まで口が開いていることがよくあります。守る側は画面に出る導線を数えて安心しますが、攻撃側は画面に出ない口まで数えます。この差が、塞ぎ漏らしを生みます。1件を返す口を1つ直しても、隣の明細や住所を返す口が同じ確認を持っていなければ、そこから漏れます。
直し方は、資源ごとに持ち主を確かめる
直しの中身はIDORと同じで、資源を返す前に持ち主を突き合わせます。BOLAで足すべき視点は、対象を1件の口ではなく、資源を返すすべての口として数えることです。注文だけでなく、明細も、住所も、それぞれの口で持ち主を確かめます。どの口が漏れているかを人手で数え切るのは難しいので、資源を返すときは必ず持ち主の確認を通す共通の仕組みを1か所に置き、口ごとの書き忘れが起きない形にします。