今回は「OWASP API Security TOP 10」の「API6:2019 Mass Assignment」について解説します。
まず、OWASPではMass Assignmentについて英語では以下のような概要で説明しています。
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
API側で多くの情報を出力することで、オブジェクトの属性が推測できたり、その情報から他のAPIなどに想定していない属性を含めてリクエストを送信し属性を変えてしまうような問題になります。
例えばある属性はある操作時に送信することを想定している値なのですが、別の操作でその情報を含めて送信するとそのまま更新できてしまいます。
具体的に例をあげると、ユーザー表示画面でAPIから出力される情報にそのユーザーに関連する情報がすべて出力されているとしましょう。この場合、テーブルで取得したデータがフィルターされずにすべて出力している状態になります。
次に、フィルターされずに出力されたユーザーの属性を記録し、別のAPI、例えばユーザー編集画面で編集できない属性の情報を含めて送信すると本来ユーザーが通常の画面から変更できない情報が更新できてしまします。
ユーザが変更できない課金情報があるとします。その金額が2,000円なのですが、100,000の値にしてその属性を含めて送信します。
下のようにユーザー編集画面からは編集できない太字の部分をリクエストに追加して送信します。本来、Web画面からのアクセスで送信しているのは太字以外の属性になりますが、Web画面から送信されるデータを改竄して黒字の部分を追加して送信します。
サーバでデータ処理する時にそのまま検証しないで保存すると、意図しない属性の値を変更することができてしまいます。
{
  ”user_id”:”xxxxx”,
  ”user_first_name”: “Ai”,
  ”user_last_name”: “Neo”,
  ”address1″: “東京都”,
  ”address2″: “港区”,
  “charge_amount”: 100000
}
これはサーバ側で検証して、編集可能な属性だけを受け付けるように制御することが必要なのですが、その検証機能が欠けるとデータを容易に改竄することができてしまいます。
Mass Assignmentのリスクをご理解いただけましたでしょうか？
最後にまとめますと、下の２つを心がけて開発してください。
1. APIから出力される情報を必要最小限にする。
2. 入力に対しても不正なデータや想定外の属性が送信されることを想定して、必要なデータだけをフィルタリングして出力する。
この２つの対応でリスクを大きく低減させることができます。
関連リンク
 
Comments