機能単位の認可管理者APIを守る｜APIセキュリティ入門

このレッスンで学ぶこと

機能単位の認可は、データの持ち主ではなく、その操作を使ってよい役割かを見る判定です。この回は、管理者向けの操作を一般利用者のトークンで呼べてしまう形、BFLA（Broken Function Level Authorization）を扱います。

読み終えるころには、200で返った口を見て、持ち主の照合と役割の判定のどちらが抜けたのかを言い分けられるようになります。

操作の側にも、同じ穴が空く

認可の枠組みで、画面がボタンを隠すことは防御にならないと確かめました。ここではそれを操作の側で具体に見ます。/admin/usersは、tanakaの画面に管理者ボタンが出ていなくても、URLを知って叩けば応答します。問題は、その応答が役割を確かめないまま返ってくることです。

http

GET /admin/users
Authorization: Bearer <tanaka のトークン>

200 OK
[{"id":"57","name":"sato"}, {"id":"58","name":"admin"}]

エンドポイントの在り処は、攻撃面を洗い出す回で見た手で分かります。JavaScriptの中の呼び出し先、/v1と/v2のように併存するバージョン、ドキュメントに載っていない経路などです。

オブジェクト単位との違い

2つは判定の軸が違います。オブジェクト単位は「このデータを触ってよいか」で、持ち主の一致を見ます。機能単位は「この操作を使ってよいか」で、役割（role）を見ます。/api/orders/1044は他人のデータを読む話でオブジェクトの側、/admin/usersやDELETE /api/users/57は管理操作そのもので機能の側です。

役割の判定を、URLの綴りに寄せない

「パスが/adminで始まるか」だけで役割を見ると、/api/admin/...や別バージョンの/v1/adminが漏れます。判定はエンドポイントの綴りではなく、その操作が管理操作かどうかに紐付けます。

手を動かして確かめる

練習用の環境で、tanakaのトークンのままGET /admin/usersやDELETE /api/users/57を送ります。管理者向けの一覧や削除が200で通れば、機能単位の認可が抜けています。直す向きは、管理操作の入口でトークンの役割がadminかをサーバー側で確かめ、そうでなければ拒むことです。確かめるのは自分が権限を持つ練習用の環境だけにします。

まとめ