BOLAとは？他人のデータにアクセスできる認可不備と対策

BOLA（Broken Object Level Authorization）は、請求書や注文など、個々のデータに対する権限確認の不備だ。ログイン済みでも、許可されていないデータを取得・変更・削除できてしまう。

例えば、自分の請求書だけを閲覧できるサービスで、他人の請求書が表示される場合が当てはまる。なぜ起きるのか、どこで権限を確認すべきかを整理する。

BOLAはなぜ起きるのか

利用者が誰かを確認するのが認証、その利用者にどの操作を許すかを判定するのが認可だ。ログインの確認が済んでも、請求書ごとの閲覧権限は別に確認する必要がある。

次は架空の例だ。サーバーが受け取った請求書IDだけでデータを検索し、そのまま返すとする。利用者Aが閲覧を許されていないBの請求書IDを指定したときにも返してしまえば、BOLAになる。欠けているのは、要求した利用者と、その請求書への権限の照合だ。

サーバーは、認証で確認した利用者について、対象データへの操作が許されているかを要求ごとに判定する。例えば、閲覧を許可された請求書の範囲から検索するか、取得した請求書への閲覧権限を確認してから返す。

閲覧できても削除は許可されない場合がある。利用者が所属する組織や共有設定も含め、サービスの権限ルールに沿って判定する。画面でボタンを隠すだけでは、サーバーへ直接送られる要求を拒否できない。

推測しにくいIDは探索を難しくする。ただし、共有リンクなどからIDが分かる場合もあるため、IDを知っていても権限外の操作は拒否する。

IDOR（Insecure Direct Object Reference）は、外から指定するIDなどの参照先を変えると、権限外のデータにアクセスできてしまう不備だ。先ほどの請求書の例は、IDの指定を通じた不正なアクセスとしてIDOR、データごとの権限確認の不備としてBOLAと説明できる。

同じ不具合を指す場合があり、名前だけで別々の問題と分ける必要はない。確認すべきなのは、誰が、どのデータに、どの操作を許されるかだ。

自社の試験環境で、権限の異なる利用者と架空の請求書を用意する。本人用・共有された請求書・閲覧権限のない請求書を分け、取得・更新・削除ごとに期待する結果を決める。拒否すべき要求でデータが返らず、保存内容も変わらないことと、許可された操作が成功することを確認する。

自社システムの認可設計やセキュリティ対策について、お気軽にご相談ください。