こんにちは。なおとです。
「Broken Object Level Authorization」はBOLAとOWASP公式でも略してあるのに、
「Broken Object Property Level Authorization」はなぜBOPLAと略してくれないのか。
お陰でこんなタイトルになりましたよ。
最近APIのセキュリティについての学習を始めました。
とっかかりとして、OWASPのAPI Security Risks Top 10を1つずつ読んでとても簡単に説明し、感想の端くれを述べていくことにしました。
OWASPとは、セキュリティに関する情報共有及び普及啓発を目的としたオープンソース・ソフトウェアコミュニティです。
API Security Risks Top 10とはOWASPが発表している、Web APIにおける10大セキュリティ懸念事項みたいです。
今回はTop 10の3つ目「Broken Object Property Level Authorization」を見ていきます。
Broken Object Property Level Authorizationとは
ユーザーが許可されていないオブジェクトのプロパティにアクセスしたり変更したりすることを許してしまうセキュリティ上の問題です。
BOLAは、ユーザーのオブジェクト自体へのアクセスの可否管理を正しくできていない問題です。
Broken Object Property Level Authorizationは、ユーザーはオブジェクト自体にはアクセスできる前提という点がBOLAと異なります。
脆弱性の原因
脆弱性の原因となるものは、OWASP公式に複数挙げられています。
例えば以下のようなものが挙げられています。
- 機密性が高く、ユーザーが読み取るべきでないオブジェクトのプロパティを公開している。(以前はExcessive Data Exposureと呼ばれていた問題です。)
- ユーザがアクセスできないはずのオブジェクトのプロパティを、ユーザが変更、追加、または削除できるようにしている。(以前はMass Assignmentと呼ばれていた問題です。)
具体例1
とあるSNSでは、ユーザーを表すオブジェクトには以下のようなプロパティが含まれます。
- ニックネーム
- 自己紹介
- メールアドレス
この中でメールアドレスだけはそのユーザー及びサービスの管理者のみが知る情報です。
ここで、サービスにはユーザーの情報を返すエンドポイント(/users/:id)があるとします。
:idを数字に変更することでその数字と一致するIDを持つユーザー情報が返されます。
:idがログインしているユーザー自身のIDと一致する場合、上記3つのプロパティに対応する情報全てを返して良いとします。
一方で、:idがログインしているユーザーのIDと一致しない場合、メールアドレスは返してはいけません。
ここでもし、:idがログインしているユーザーのIDと一致しない場合も、メールアドレスを含めた情報を返してしまう作りをしていた時、Broken Object Property Level Authorizationの問題が発生していると言えます。
この例はExcessive Data Exposureですね。
具体例2
とあるSNSでは、投稿内容を表すオブジェクトには以下のプロパティが含まれます。
- 投稿文
- 画像
- 警告フラグ
サービス管理者は、不適切な表現を含む投稿の警告フラグをオンに変更し、一般公開されないようにします。
もちろん警告フラグは投稿者からは変更されてはならないプロパティです。
ここで警告フラグをオンにされた投稿のユーザーが、投稿編集機能にて、警告フラグをオフにするようなパラメータを付与したリクエストをAPIに送ったとします。
もしこのリクエストによって、警告フラグを変更できてしまった場合、不適切な表現を含む投稿が一般公開されてしまいます。
この時、Broken Object Property Level Authorizationが発生していると言えます。
この例はMass Assignmentですね。
対策
- APIエンドポイントからオブジェクトを公開する時、各プロパティへのユーザーのアクセス可否を常に確認すること。
- オブジェクトに対してto_json()やto_string()を使うなど、返すデータを雑に作成することをやめること。
- ユーザーの入力をそのままオブジェクトのプロパティとして代入することは避けること。
- クライアントが更新できるオブジェクトのプロパティにのみ変更を許可する。
- レスポンスに正しい情報のみ含まれているかチェックするバリデーションを組む。
- エンドポイントの要件に従って、返されるデータを必要最低限に抑える。
以上で簡単なBroken Object Property Level Authorizationについての説明とさせていただきます。
技術的な感想
-
Mass Assignmentについて
例えば、ユーザーから送信されるパラメータを受け取って検証する関数を用意し、そのメソッドをデータ新規作成にも、データ更新にも使い回すということがあるかもしれません。
機密なプロパティが含まれている場合は、そのプロパティが更新されないよう、パラメータの検証用関数をデータ新規作成、データ更新用にそれぞれ作成すると良いと思います。
最後に
今回の問題は、日々の実装でもすでに気をつけていることだなと思いました。
対策を見直して、さらに注意深く実装しようと思えました。
この記事の説明は本当に簡単に行っています。
しっかり学びたい方は是非公式の文章を読んでみてください。
最後まで読んでいただき、ありがとうございました。