Mass Assignment

Mass Assignmentとは何か？

最近のアプリは、オブジェクト（例：ユーザ、プロダクト等）に依存しており、これらのオブジェクトは各プロパティ（例：product.stock）を持っております。利用者は、特定のプロパティの編集や閲覧が許可される一方で、編集や閲覧できないプロパティも存在します（例：ユーザはproduct.stockを閲覧できても、編集はできません）。これらのプロパティはフロントエンドのパラメータと対応付けられており、変換が自動で行われる場合、攻撃者がアクセスすべきではないプロパティにパラメータが変換される可能性があります（例：ユーザがPUTリクエストを送った際、フロントエンドがパラメータ "title" をproduct.titleに変換してしまうことがあります）。

こちらは、利用者が編集してはならないその他のプロパティの例です：

• Account.AccountType または Account.discountsEnable。これらは権限に関するプロパティです。
• Account.wallet。このプロパティは攻撃者が編集することは決して許されません。
• product.title。内部のプロパティであり、利用者が編集すべきではありません。

‍

攻撃シナリオの例

これらの攻撃シナリオは、バグバウンティハンターとしての個人的な経験に基づいております。この問題は見逃しやすく、必要な論理知識が要求されるため自動化して検出することが難しい点が特徴です。

最初の例は、1時間の予約が可能なアプリからのものです。UI上で1時間のタイムスロットが表示され、その中から一つを選択することができます。

‍

‍

リクエストを確認していたものの、最初は気付かず、認識するまでに約1時間を要しました：

{
    "startDate":"29/04/2022 11:00",
    "endDate":"29/04/2022 12:00",
    "userID":"123",
    "consultant ID":"123"
}

開始日または終了日を変更することで、希望次第ではコンサルタントの予定を何年も埋め尽くすことが可能です。見逃しやすい点が、この問題の巧妙なところです。

{
    "startDate":"29/04/2022 11:00",
    "endDate":"29/04/2099 12:00",
    "userID":"123",
    "consultant ID":"123"
}

次の例は、ハッキングの際にアカウント設定を確認し、APIレスポンス内に本来編集できないプロパティが含まれていないかを探すというものです。例えば、自社の管理者権限を獲得するための手段ですが、これはさらに微妙なバグに該当します。

Request:

{
    "endDate":"29/04/2099 12:00",
    "userID":"123",
    "consultant ID":"123"
}

Response from API:

{
    "AccountType":"airport",
    "endDate":"29/04/2099 12:00",
    "userID":"123",
    "consultantID":"123"
}

このレスポンスには、リクエストには含まれていない2種類のアカウントタイプが存在しております。しかし、もしそのパラメータをコピーすれば、APIが自動的にオブジェクトへマッピングするため、変更可能となる恐れがあります。

Request:

{
    "endDate":"29/04/2099 12:00",
    "userID":"123",
    "consultant ID":"123",
    "AccountType":"airline",
}

Response from API:

{
    "AccountType":"airline",
    "endDate":"29/04/2099 12:00",
    "userID":"123",
    "consultant ID":"123"
}

もう一つの微妙な点は、アカウントタイプの変更自体が深刻な問題であることです。対象外とされる場合でも、公開資産であるウェブサイト（www.FAKEPAGE.com）を確認すると、一方のアカウントタイプは他方に比べてかなり高額なため、影響が大きくなることが判明いたしました。

‍

Mass Assignmentへの予防策

• 可能な限り、プロパティの自動マッピングを無効にし、全てのプロパティは手動でマッピング、不要なものは無視するようにすべきです。

• 利用者が編集してはいけないデータは、ブロックリストに頼るのではなく、特定のオブジェクトのみを編集可能とするホワイトリストを使用すべきです。これにはアプリの論理やプロパティを十分に把握する必要があり、リソースを要しますが、その分セキュリティ性が向上するため、追加コストに見合う対策となります。

• ブラックリストやホワイトリストの実装には、独自のコードではなくフレームワークの機能を活用すべきです。これらの機能は十分なテストが行われているため、カスタム実装よりも安全性が高い傾向にあります。

• 余力がある場合は、APIに届くリクエストやレスポンス、及びそれらに含まれるプロパティを調査し、利用者が編集できるはずのないパラメータが実際に読み取り専用になっているかどうか、リクエストを送信して検証することが推奨されます。

‍

‍

結論

ご覧の通り、各パラメータの機能について十分に検討し、その意味や選択肢を正しく理解することが重要です。API内の全プロパティを調査し、使用されていないものが本番環境へ送信され悪用されることがないよう注意してください。また、API保護もお忘れなく。Wallarmでは、数百万件のセーフティレポートに基づき2021年OWASP Top 10をまとめておりますので、ぜひご参照ください。