権限昇格 一般利用者が管理者になる

このレッスンで学ぶこと

権限昇格は、一般利用者のtanakaが、本来は管理者adminにしか許されていない機能を使えてしまう欠陥です。認可の崩れ方のうち、役割をまたいで上に上がる垂直の形にあたります。

読み終えると、画面に出ていない入口を自分で叩いて、役割の判定が入っているかを確かめられるようになります。

リンクを消しても、機能は消えない

練習用のショップで、tanakaとしてログインします。画面には管理メニューが出ていません。ところがURL欄に/admin/usersと直接打ち込むと、全利用者の一覧がそのまま返ります。

GET /admin/users   ログイン中 = tanaka
  → 200  全利用者の一覧が返る

メニューからリンクを消したのは、画面の表示を変えただけです。その先の/admin/usersというエンドポイントは、開いてきた主体が管理者かどうかを一度も確かめていません。リンクが見えるかどうかと、機能が動くかどうかは別の層の話で、攻撃者はリンクをたどらず直接URLを打ちます。画面に出ていない入口を手で叩いて回るこの探し方を、強制ブラウジングと呼びます。

推測できるURLは、鍵ではない

管理者用のURLは/admin/usersや/admin/ordersのように素直な名前が多く、いくつか試せば当たります。では推測できない長い名前にすれば安全かというと、そうではありません。名前を秘密にするのは、認可の代わりにはなりません。URLを知っている人には何も変わらないからです。

秘密のURLは、漏れた瞬間に守りが消えます。ブックマーク、共有された画面、通信の記録など、URLが人目に触れる経路はいくらでもあります。守るなら、URLの秘密ではなく、開いてきた人の役割で判定してください。

直し方は、役割をサーバーで確かめる

管理者用の各エンドポイントで、開いてきた主体の役割がadminかどうかを、資源を返す前に確かめます。既定は拒否にして、adminのときだけ通します。

GET /admin/users
  → ログイン中の主体の役割を見る
  → admin でなければ拒否して終わり
  → admin のときだけ一覧を返す

役割を返すのはサーバーが持つ情報からで、リクエストが名乗ってきた役割を信じてはいけません。名乗りを信じる形が次にどう破れるかは、この先の回で扱います。

まとめ