アクセス制御の不備とは？ログインと閲覧の許可が別な理由

アクセス制御の不備とは、本来は許可された人だけが使える情報や機能に、許可のない人が触れられてしまう問題です。ログインで本人を確かめるだけでなく、その人に、その情報を見せてよいかを確認する必要があります。

会員サイトへ入れたとしても、ほかの会員の注文履歴まで見てよいわけではありません。「入れる」と「扱ってよい」の間を分けるのが、アクセス制御の役目です。

アクセス制御とは誰が何を見てよいかを決めること

アクセス制御は、情報や機能を、誰がどの範囲で使えるかを制限する仕組みです。読むだけでなく、変更する、削除する、公開するといった操作も含まれます。

ここでよく出てくる言葉が、認証と認可です。

ログインの仕組みが正しく働いていても、認可の確認が抜ければ、他人の情報へ届く場合があります。入り口だけを守れば、その先も全部守られるとは限りません。

自分のものかどうかだけで決まる？

必ずしも所有者だけが見られるわけではありません。家族やチームで共有する資料なら、持ち主以外にも閲覧を許すことがあります。管理担当者に、特定の操作を認める場合もあります。

だから必要なのは、「自分の情報か」だけではなく、この利用者に、この対象への、この操作を認めているかという確認です。

たとえば、読むことは許されていても、削除までは許されていない資料があります。「アクセスできるか」を一つの丸かバツで扱わず、何の操作かも分けます。

IPAのアクセス制御・認可制御の説明でも、認証に加え、利用者ごとにどの操作を許すかを制御する必要性が示されています。

IDORで番号を知ることと閲覧の許可が混同される

IDORは、アクセス制御の不備の一つです。情報を指定する番号や名前などを悪用し、本来は許されていない他人の情報へアクセスできてしまう問題を指します。

名前は難しく見えますが、見るべき点は一つです。情報を指定できることと、その情報を扱う許可があることは違うということです。

注文番号が分かっても、その注文の持ち主とは限らない

注文履歴を見る場面では、サイトが注文番号を使って、どの記録を表示するか決めることがあります。ここで、送られてきた番号の記録が「存在する」ことだけを確認し、その利用者に見せてよいかを確認しなければ、他人の記録が出てしまうおそれがあります。

番号は、情報を探すための目印です。番号を知っているだけで、正当な利用者だと証明されたわけではありません。

MDNのIDOR解説も、ログインを確認するだけでなく、要求された対象へアクセスする権限をサーバー側で確かめることを、中心的な対策としています。

これは仕組みを理解するための説明です。利用中のサービスで、他人の番号を探して試す必要はありません。

長くて推測しにくい番号なら安全？

番号を推測しにくくすることは、情報の場所を見つけにくくする助けになります。しかし、その番号が何らかの形で知られたときに、誰でも見られるなら、許可の確認は足りないままです。

同じように、管理者用のボタンを画面から消すことと、管理者以外の要求をサーバーが拒否することは別です。画面に操作の入口がなくても、プログラム同士が情報をやり取りするAPIなどの経路が残る場合があります。

アクセス制御の不備には、IDOR以外にも、一般の利用者が管理者用の機能を使えてしまう問題などがあります。IDORとアクセス制御の不備全体は、完全な同義語ではありません。

アクセス制御の不備は利用者が直せる？

プログラム側で許可の確認が抜けている場合、通常は開発・運用側の修正が必要です。利用者がパスワードを変えるだけで、その確認が追加されるわけではありません。

一方、サービスが用意する共有設定を広くしていたために情報が見えている場合は、その設定の見直しが関わります。設定どおりに公開されていたのか、許可していない人にも見せる不備があったのかで、調べる場所が違います。

運営側は、対象と操作ごとに確かめる

運営側は、情報を返すときや変更を受け付けるときに、その利用者へ操作を認めているか確認します。新しい画面だけでなく、APIやファイルの取得など、同じ情報へ届く別の経路も対象です。

確認するなら、許可されたテスト環境と架空のデータを使い、利用者の役割を変えて見る必要があります。自分のアカウントで正しく表示できることだけでは、他人へ表示されないことまでは分かりません。

たとえば、共有メモなら、次のように期待する結果を決めておくと、担当者同士で話を合わせやすくなります。

これは説明用の設計例で、どのサービスもこの三種類で十分という意味ではありません。実際に許す範囲を決め、その範囲と動作が一致するかを確かめます。

見えてはいけない情報に気付いたら

別の利用者の情報らしいものが出たときは、原因を自分で確かめようと、さらに番号や操作を変えて調べないようにします。表示された情報をSNSへ載せたり、関係のない相手へ送ったりする必要もありません。

その時刻、使っていた画面、自分が行った操作などを整理して、サービスの公式窓口へ連絡します。情報の保存や提出が必要な場合は、窓口の案内に沿って、必要な範囲で行います。

表示を見ただけで、IDORなのか、共有設定なのか、別の不具合なのかは断定できません。利用者は無理に原因名まで特定せず、「何が起きたか」を伝えれば調査の助けになります。

脆弱性の報告で「アクセス制御の不備」と出たら、誰が、どの情報に、何をできてしまったのかを読むと、問題の範囲が見えます。ログインだけでなく、その先の許可まで確かめる仕組みが、利用者同士の情報を分けて守っています。