認可の不備

認証はあなたが誰であるかを証明します。認可はあなたが何をしてよいかを決定します。

認可の不備があると、システムによってユーザーが本来許可されていない操作をしたり、情報を見たりできてしまいます。

BOLAはBroken Object Level Authorizationの略です。

これはAPIにおける最も重大なリスクです。APIはログイン済みであることは確認しますが、要求された特定のオブジェクトが実際にそのユーザーのものかどうかを確認しません。

あなたのアカウントがユーザー100だとします。

IDを変更してもサーバーが応答するなら、他人の注文を読み取れてしまいます。これがBOLAです。

開発者は、リクエスト内のIDを信頼してしまうことがあります。

ログイン中のユーザーがそのオブジェクトを実際に所有しているかの確認を忘れてしまうのです。対策は、すべてのリクエストで所有者を確認することです。

もう1つの脆弱性がBFLA（Broken Function Level Authorization）です。

エンドポイントがユーザーのロールを確認しないため、一般ユーザーが管理者専用の操作を呼び出して実行できてしまいます。

管理者用のルートを考えてみましょう。

一般ユーザーがこれを呼び出して成功するなら、APIはロールベースのアクセス制御を適用できていません。

APIによっては、リクエストのフィールドをレコードに無条件でマッピングします。

ユーザーがプロフィール更新にrole=adminのようなフィールドを追加すると、気付かれないまま自分の権限を昇格できる可能性があります。

ボタンやフィールドを非表示にする処理をクライアントに任せないでください。

攻撃者はUIを完全に迂回してリクエストを直接送信できるため、すべての認可判断はサーバーで適用する必要があります。

連番のIDはBOLAを簡単に悪用できるようにします。

UUIDのようなランダムな識別子を使っても認可チェックの代わりにはなりませんが、次の番号を推測するだけの攻撃は防げます。

安全なAPIはデフォルトで拒否します。

明示的なルールによって許可された場合にのみアクセスを認めます。これにより、チェックが抜けていてもデータを漏らすのではなく、アクセスを閉じた状態にできます。

認可のバグは見つけにくいため、意図的にテストしてください。

自分のトークンを使って、別のユーザーのデータへのアクセスを試みます。成功した場合は、修正が必要な重大な脆弱性を発見したことになります。

APIはログイン済みであることを確認しますが、IDを変更すると別のユーザーのレコードを返します。これはどの脆弱性ですか？

認可の不備があると、ユーザーが本来アクセスできないものにアクセスできてしまいます。BOLA、BFLA、マスアサインメントに注意してください。

所有者とロールのチェックをサーバーで適用し、デフォルトで拒否し、認可を意図的にテストしてください。