IDORとは

WebアプリケーションやWebサービスにて、データの参照に対して適切なアクセス権限がされていないために任意のデータを参照できてしまう問題です。

この問題が発生する例を挙げると、サービスの利用者が登録した利用者個人の情報は、他の利用者から参照されたくないはずなのに、パラメータないしはURLを追加・編集すると参照できてしまう状態です。

具体例

通信販売をインターネットで行い、商品を販売する店舗と購入者の両方が利用するオンラインサービスを例に挙げます。
店舗は、自店舗で販売する商品をサービスへ登録や編集ができ、在庫の補充、商品の販売停止などもできます。これらの機能は同サービスで提供しており、認証した店舗のみが利用できます。

この条件下で、店舗で販売している商品をすべて検索するAPIが以下で提供されていたとします。このAPIでは、編集中の商品や未公開になっている商品も取得できるものです。

https://api.example-service.com/tenant/{tenantId}/items

{tenantId} の部分は、サービスから各店舗に割り振られた一意の値です。各店舗が画面から商品検索をする際にはこの tenantId は特に指定せずとも画面から自動的に渡して検索するような設計にしたとしましょう。

検索ボタンを押したときに期待するURLは、tenantId が 0001 だった場合

https://api.example-service.com/tenant/0001/items

をリクエストし、その結果が受け取れます。同様に他の店舗も tenantId が 0002 , 0003 と割り振られているので、同様に {tenantId} の値を変えることで検索結果が得られます。

この検索結果は、サービスの認証をしている一部の店舗だけが利用できたとしても、次の問題があります。

今回の例では、tenantId は連続する番号なのですぐに特定できますが、これは tenantId の値が複雑～例えばUUIDであったとしても～複雑性を増したところで偶然ないしはいつか判明してしまいます。

このように一部のパスやパラメータを書き換えたりするだけで、本来参照されたくない情報を取得できてしまう脆弱性のことを IDOR（Insecure Direct Object Reference）: 直接参照の不備 と呼びます。

これは検索だけでなく、登録や更新処理でも同様で、認証済みの状態ならURLやパラメータさえ知っていれば任意のデータに書き換えできてしまう問題もあるわけです。

また、店舗の登録情報を参照できるAPIがあった場合、店舗情報には振込先の銀行口座、個人名など、公開したくない情報があった場合に、他店舗の秘匿情報が取得できてしまう＝重大な情報漏洩になります。

この例でいえば、認証後のアクセス制御が「ロール基準」だけだったことが原因です。

「出店している店舗だったら店舗用のAPIが利用できる」としているため、店舗でログインできた場合は他の店舗情報も利用できてしまう考慮がなされていません。

サービス側はリクエストされたURLやパラメータに対して、データの取得範囲や更新内容が適切な権限を持ちうるかのアクセス制御をつけます。

今回の例でいえば、リクエストされた tenantIdの値が、ログインしている端末の認証情報から参照可能な店舗と一致しているかを確認して、アクセスの許可または拒否を判断する設計をするべきでしょう。