コーダーズ・コンカー・コンカー・セキュリティ：シェア＆ラーニング・シリーズ-アクセス制御の破損
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
%20(1).avif)
.avif)
