M6 - 安全でない認可
脅威エージェント
アプリケーション依存
認可の脆弱性を悪用する脅威エージェントは一般的に利用可能なツールやカスタムツールを使用した自動化された攻撃を行います。
攻撃手法
悪用難易度 容易
攻撃者は認可スキームがどのように脆弱であるかを理解すると、正規のユーザーとしてアプリケーションにログインします。彼らは認証コントロールを正常に通過します。一度認証を通過すると、一般的に脆弱なエンドポイントに強制ブラウズして管理機能を実行します。このサブミッションプロセスは一般的にデバイス内のモバイルマルウェアや攻撃者が所有するボットネットを介して行われます。
セキュリティ上の弱点
普及度 中 検出難易度 普通
認可スキームの不備をテストするために、テスト担当者はモバイルアプリに対してバイナリ攻撃を行い、モバイルアプリが 'オフライン' モードである間に高い権限を持つユーザーでのみ実行できる特権機能を実行しようと試みます (バイナリ攻撃についての詳細な情報は M9 および M10 を参照ください) 。同様に、テスト担当者はバックエンドサーバーに対する機密性の高い機能について、対応する POST/GET リクエスト内の低い権限のセッショントークンを使用して、特権機能を実行しようと試みるべきです。認可スキームの不備や不在は、攻撃者が認証されているが低い権限のモバイルアプリのユーザーを使用して、権限を与えられるべきではない機能を実行することが可能となります。認可要件はリモートサーバーを通す代わりにモバイルデバイス内で認可の決定を行う場合により脆弱となります。これはオフラインユーザビリティのモバイル要件のために必要となる可能性があります。
技術的影響
影響度 深刻
脆弱な認可の技術的影響は脆弱な認証の技術的影響と本質的に同様です。技術的影響は本質的に幅広く、実行される特権機能の性質に依存します。例えば、リモートもしくはローカルの管理機能の特権実行はシステムの破壊や機密情報へのアクセスを引き起こす可能性があります。
ビジネスへの影響
アプリケーション / ビジネス依存
ユーザー(匿名もしくは検証済み)が特権機能を実行できる場合、ビジネスには以下のような影響があります。
風評被害
なりすまし
情報漏洩
'安全でない認可' の脆弱性があるか？
認証と認可の違いを認識することが重要です。認証とは個人を特定する行為です。認可とは特定された個人が行為を実行するために必要なパーミッションを持っているかどうかを確認する行為です。認可チェックは常にモバイルデバイスからの受信リクエストの認証に即座に追従するため、2つは密接に関連しています。
モバイルデバイスからリクエストされた API エンドポイントを実行する前に組織が個人の認証に失敗した場合、コードは自動的に安全でない認可を受けることになります。発信者の同一性が確立されていない場合、受信リクエストに対して認可チェックを行うことは本質的に不可能です。
モバイルエンドポイントが安全でない認可を受けているかどうかを判断しようとするときには、従うべき簡単なルールがあります。
安全でないオブジェクト直接参照 (Insecure Direct Object Reference, IDOR) 脆弱性の存在 - 安全でないオブジェクト直接参照脆弱性 (IDOR) を目にしている場合、コードは有効な認可チェックを実行していない可能性が最も高くなります。
非表示のエンドポイント - 通常、開発者は非表示の機能が適切なロールを持つ人にしか見えないと仮定しているので、バックエンドの非表示の機能に対して認可チェックを実行しません。
ユーザーロールやパーミッションの送信 - モバイルアプリがリクエストの一部としてバックエンドシステムにユーザーロールやパーミッションを送信している場合、安全でない認可を受けています。
'安全でない認可' を防ぐには？
安全でない認可チェックを避けるには、以下を行います。
バックエンドシステムに含まれる情報のみを使用して認証されたユーザーのロールとパーミッションを確認します。モバイルデバイス自体からくるロールやパーミッションの情報に依存するのは避けます。
バックエンドコードは識別情報を伴うリクエスト(リクエストされた操作のオペランド)に関連付けられた受信識別子が受信IDと一致し属することを独立して検証すべきです。
攻撃シナリオの例
シナリオ #1: 安全でないオブジェクト直接参照:
ユーザーはバックエンド REST API にアクター ID と oAuth ベアラートークンを含む API エンドポイントリクエストを行います。ユーザーは受信 URL の一部としてアクター ID を含め、リクエストの標準ヘッダーとしてアクセストークンを含めます。バックエンドはベアラートークンの存在を検証しますが、ベアラートークンに関連付けられたアクター ID の妥当性確認を行いません。その結果、ユーザーは REST API リクエストの一部であるアクター ID に手を加え、他のユーザーのアカウント情報を取得できます。
シナリオ #2: LDAP ロールの送信:
ユーザーはバックエンド REST API にユーザーが所属する LDAP グループのリストを含むヘッダを伴い標準 oAuth ベアラートークンを含む API エンドポイントリクエストを作成します。バックエンドリクエストはベアラートークンを確認してから、機密性の高い機能を続行する前に受信 LDAP グループが正しいグループメンバーであることを検査します。しかし、バックエンドシステムは LDAP グループメンバーであることの独立した確認を実行せず、代わりにユーザーからきた受信 LDAP 情報に依存します。ユーザーは受信ヘッダーに手を加えて勝手に任意の LDAP グループのメンバーであるとレポートし、管理機能を実行します。
参考資料
OWASP
Last updated