ブログ

Coders Conquer Security OWASP Top 10 API Series - Mass Assignment

マティアス・マドゥ博士
2020年10月21日発行

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

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

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

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

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

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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

リソースを見る
リソースを見る

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

ご興味がおありですか?

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。

デモを予約する
シェアする
著者
マティアス・マドゥ博士
2020年10月21日発行

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。

Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。

シェアする

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

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

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

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

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

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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

リソースを見る
リソースを見る

以下のフォームに記入し、レポートをダウンロードしてください。

弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

送信
フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。

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

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

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

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

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

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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

リソースにアクセス

以下のリンクをクリックし、この資料のPDFをダウンロードしてください。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。

レポートを見るデモを予約する
PDFをダウンロード
リソースを見る
シェアする
ご興味がおありですか?

シェアする
著者
マティアス・マドゥ博士
2020年10月21日発行

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。

Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。

シェアする

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

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

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

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

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

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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

目次

PDFをダウンロード
リソースを見る
ご興味がおありですか?

Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。

デモを予約するダウンロード
シェアする
リソース・ハブ

始めるためのリソース

その他の記事
リソース・ハブ

始めるためのリソース

その他の記事