大量割り当ての脆弱性が生まれたのは、最近のフレームワークの多くが、クライアントからの入力をコードの変数や内部のオブジェクトに自動的に束縛する関数の使用を開発者に推奨しているからです。これは、コードを単純化し、操作を高速化するために行われます。

攻撃者は、この手法を用いて、クライアントが決して更新してはならないオブジェクトのプロパティを強制的に変更することができます。通常、これは、ウェブサイトをダウンさせたり、企業秘密を盗んだりするのではなく、ユーザが自分自身に管理者権限を追加するような、ビジネス特有の問題につながります。また、攻撃者は、オブジェクト間の関係や、悪用しようとするアプリケーションのビジネスロジックについてもある程度把握していなければなりません。

しかし、いずれの場合も、巧妙で悪意のあるユーザーの手にかかれば、大量割り当ての脆弱性の危険性は低くなりません。

その前に、ゲーム性を持たせた課題をプレイしてみてはいかがでしょうか。

攻撃者はどのようにして大量割り当ての脆弱性を利用するのでしょうか？

OWASP が提示したシナリオ（私たちは少し修正しました）では、ライドシェアのアプリケーションを想定しています。このアプリケーショ ンには、大量割り当てを使用してコード内のオブジェクトにバインドされたさまざまなプロパティが含まれています。これらには、ユーザが変更できる許可関連のプロパティと、アプリケーションが内部でのみ設定すべきプロセス依存のプロパティがあります。どちらもオブジェクトにプロパティをバインドするために大量割り当てを使用しています。

このシナリオでは、多くのユーザー向けアプリケーションで一般的に行われているように、ライドシェアアプリケーションがユーザーにプロフィールの更新を許可しています。これは、PUTに送られたAPIコールを使用して行われ、次のJSONオブジェクトが返されます。

{"user_name":"SneakySnake", "age":17, "is_admin":false}

攻撃者（この場合はSneakySnake氏）は、プロパティとオブジェクトの関係を把握しているので、自分のプロフィールを更新する最初のリクエストを以下の文字列で再送信することができます。

{"user_name":"SneakySnake","age":24,, "is_admin":true}

エンドポイントは大量割り当てに対して脆弱なため、新しい入力を有効なものとして受け入れます。このハッカーは、自分のプロフィールに数年分を追加しただけでなく、自分に管理者権限を割り当てました。

マスアサインメントの脆弱性の解消

一部のフレームワークでは大量の代入機能が使えて便利かもしれませんが、APIの安全性を保ちたいのであれば、そのようなことは避けるべきです。代わりに、リクエストの値をオブジェクトに直接バインドするのではなく、パースします。また、縮小されたデータ転送オブジェクトを使用することで、オブジェクト自体に直接バインドするのとほぼ同じ利便性を得ることができますが、関連するリスクはありません。

さらなる予防策として、上記の例にある管理者権限のような機密性の高いプロパティを拒否して、APIコールでサーバーに受け入れられないようにすることもできます。さらに、すべてのプロパティをデフォルトで拒否し、ユーザーに更新や変更をさせたい特定の非センシティブなプロパティを許可するという方法もある。これらのいずれかを行うことで、APIをロックし、環境から大量割り当ての脆弱性を排除することができます。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。