LCNC-SEC-02: 認可の誤用
リスク評価 *
3
3
3
3
要旨
コネクションはほとんどのローコード/ノーコードプラットフォームでファーストクラスのオブジェクトです。 これはアプリケーション、他のユーザー、組織全体の間でコネクションが確立され、アプリケーションが削除されてもコネクションが「オン」のままとなることを意味します。 また、アプリケーションはその基盤となるデータにアクセスすべきでないユーザーと共有できてしまいます。 さらに、アプリケーションはユースケースの要件を超える幅広い認可スコープをもつこともあります。
ビジネスユーザーへの説明
アプリケーションを記述する際、ユーザーの身元を確認 (認証) し、そのアプリを使用するときにユーザーが持つアクセス権限のレベルを定義 (認可) することが重要です。認可の誤用はユーザーがシステムで何ができるかをアプリケーションが誤って定義した場合に発生します。
説明
ローコード/ノーコード開発はサイロ (縦割り組織) で行われるものではありません。 その影響はオンプレミス、SaaS、PaaS、クラウドプラットフォームにまたがり統合された組織のスタック全体に及びます。 ほとんどのローコード/ノーコードプラットフォームには多数のコネクタセット、つまり API のラッパーが多数組み込まれており、すばやく簡単に接続できます。 コネクタとユーザー資格情報はコネクションを形成し、ほとんどのローコード/ノーコードプラットフォームで主にファーストクラスのオブジェクトとなります。 これはアプリケーション間、他のユーザー、または組織全体でコネクションが共有できることを意味します。
多くのローコード/ノーコードプラットフォームは OAuth 認証フローを悪用して、ユーザーリフレッシュトークンをクエリして保存し、それらを勝手に再利用することで生産性を高め、配信までの時間を短縮しています。 これによりビジネスユーザーはシークレットやパーミッションについて考えることなくコネクションをすばやく設定できますが、同時に、コネクションには監視や取消が難しいユーザー ID が組み込まれてしまいます。 OAuth リフレッシュトークンは有効期限が短くなるように設計されていますが、ほとんどの場合、数か月から数年も有効であることがよくあります。 したがって、ビジネスユーザーが短時間で作成したコネクションは、ローコード/ノーコードプラットフォームで長期間存続し、他のユーザーによって本来の意図とは異なる目的で使用されることがよくあります。
認可スコープは組織のリソースや資産へのアクセスをコントロールします。 ローコード/ノーコード開発者はアプリケーションの認可スコープを幅広くし、できるだけ汎用的なものにすることを好みます。 組織にとっては、これによってアプリケーションを迅速かつ容易にセットアップでき、後で他のアプリケーションを必要とせずに他のユースケースに使用できます。 認可スコープを幅広くすることで、認可の誤用という不必要なリスクが伴います。
攻撃シナリオの例
シナリオ #1
ある開発者は企業の電子メールアカウントへのコネクションを作成しました。 うっかり「全員で共有」オプションをクリックして、使用権限または完全な所有権のいずれかを付与してしまいます。 企業内のすべてのユーザー (請負業者やベンダーを含む) が企業の電子メールアカウントにアクセスできるようになります。 悪意のあるユーザーは「パスワードを忘れた場合」のフローをトリガーし、コネクションを使用してプロセスを実行し、アカウントをコントロールします。
シナリオ #2
ある開発者はデータベースからレコードを閲覧するためのシンプルなアプリケーションを作成しました。 このアプリケーションは各ユーザーが関連するレコードのみを閲覧できるように権限を設定しています。 しかし、アプリケーションは基盤となるデータベースコネクションがそのユーザーと暗黙のうちに共有されるように設定されています。 アプリケーションのユーザーはデータベースコネクションを直接使用して、すべてのレコードへの完全なアクセスを取得できます。
シナリオ #3
管理者はサービスアカウントまたはアプリケーションアカウントを使用してアプリケーションをソースコード管理システム (Bitbucket など) に接続します。 提供されたこのサービスアカウントまたはアプリケーションアカウントはシームレスな統合を可能にするためにすべてのリポジトリに無制限にアクセスできます。 内部ユーザーはこのコネクションを悪用して、通常はアクセスできない制限付きリポジトリにアクセスできます。
シナリオ #4
ある開発者はあるプラットフォームから別のプラットフォームへフォームを送信するシンプルなアプリケーションを作成しました。 しかし、このアプリケーションはフォーム送信を作成するだけで十分なはずなのに、フォーム送信の編集と削除の認可を必要とするように設定されています。
攻撃と悪用のシナリオの例 - ビジネスユーザー
シナリオ #1
ある開発者は財務システムへの経費項目の入力を自動化し、入力と承認のプロセスを自動化するように依頼されました。財務プロセスではトランザクションを入力するユーザーとアクションを承認するユーザーとの間で権限を分離する必要があります。この自動化は誤った認可で構築されているため、このプロセスを実行しているユーザーは誰でも両方のタスクを実行できます。
シナリオ #2
保険会社で、ある開発者は新しい個人向け自動車保険契約の受付プロセスを簡素化するアプリケーションを構築するように依頼されました。このアプリケーションは大成功を収め、商用自動車保険のユーザーがこのアプリケーションを使い始めました。
商用自動車保険のプロセスにはこのアプリケーションの構築時には計画されていなかった追加の検証項目があり、プロセスの後半で重大な価格設定エラーが発生します。
その開発者は他部門での使用を想定していなかったため、適切な認可設定でアプリケーションを設計していませんでした。
シナリオ #3
ビジネスインテリジェンス (BI) レポートは部門全体の従業員の経験と給与を分析するために作成されます。このレポートは上級管理職のみを対象としていますが、認可スコープが広く設定されており、どの部署の誰でも従業員に関する詳細情報を閲覧できます。
上級管理者がこのレポートをチームと共有すると、会社全体のすべての給与を確認し、互いの給与を比較できてしまいます。
防止方法
暗黙のうちに共有されるコネクションを使用できないようにするか、または監視する。
共有コネクションを含む可能性がある環境へのアクセスを提供する際には、最小権限の原則を遵守する。
ノーコード/ローコードプラットフォームの過剰な共有コネクションを監視する。
コネクション共有のリスクと資格情報共有との関係についてビジネスユーザーに教育する。
コネクションを再認証することにより、OAuth トークンを定期的に明示的にリフレッシュする。
アプリケーションが必要とするスコープを慎重にレビューし、最小権限の原則を順守する。
参考資料
Last updated