| 脅威エージェント | 攻撃経路 | セキュリティ上の弱点 | 技術的な影響 | ビジネスへの影響 | |
|---|---|---|---|---|---|
| アプリ依存 | 攻撃難易度 容易 | 蔓延度 中 | 検出難易度 中 | 影響度 重大 | アプリ / ビジネス依存 |
| 一般的に、攻撃者はバックエンドシステムの隠し機能を見つけるために、モバイルアプリに作り込まれた余計な機能を調べようとします。攻撃者は通常、エンドユーザとは関係なく、攻撃者自身のシステムから直接、余計な機能を悪用します。 | 攻撃者はモバイルアプリを攻撃者自身のローカル環境にダウンロードして調査します。攻撃者は開発者によって残された隠しスイッチやテストコードを見つけるためにログファイル、設定ファイル、そしておそらくバイナリ自体も調査します。攻撃者は、バックエンドシステム内のこのようなスイッチや隠し機能を悪用し攻撃します。 | モバイルアプリが、ユーザにインタフェースを介して直接提供される機能以外の余計な機能を内包している可能性は高いです。この余計なコードのほとんどは、事実上無害で、攻撃者にバックエンドの特性をさらに示唆するわけではありません。しかし、余計な機能のいつくかは、攻撃者にとても有益なものが含まれています。バックエンドのテスト、デモ、ステージング環境やUAT環境に関連する情報を晒してしまう機能は、プロダクションビルドに含まれるべきではありません。さらに、管理者用のAPIエンドポイントや非公式のエンドポイントについても、最終的なプロダクションビルドに含まれるべきではありません。本来の機能以外の機能を検査することは、とてもトリッキーです。静的解析ツールや動的解析ツールで、簡単なもの（ログステートメント）は検出できます。しかし、自動化された手段では、バックドアの検出は困難です。したがって、これらを防ぐためには、手動のコードレビューが最善策といえるのです。 | 余計な機能に関する技術的影響は以下です。
|
余計な機能に関するビジネスへの影響は以下です。
|
|
開発者はしばしば、本番環境にリリースするつもりのない隠れたバックドア機能や内部開発用のセキュリティコントールを含めてしまいます。例えば、ハイブリッドアプリ内にパスワードをうっかりコメントとして含めてしまうかもしれません。他には、テスト中から二要素認証を無効化にしていたままのこともあります。 本リスクの重要な特徴は、リリースするつもりはない余計な機能をアプリケーション内で有効にしたままにしてしまうことです。
本脆弱性を防止する最も良い方法は、セキュリティに一番詳しい人や該当のコードについて最も詳しい専門家にセキュリティ観点で手動のコードレビューを実施してもらうことです。彼らは以下を実施する必要があります。
- 隠しスイッチを見つけるためにアプリの設定を調査する
- 全てのテストコードがアプリの最終のプロダクションビルドに含まれていないことを検証する
- モバイルアプリからアクセスされる全てのAPIエンドポイントを調査して、それらのエンドポイントについて十分にドキュメント化され、一般公開されているかどうかを検証する
- バックエンドについて過剰な記述がログに書き出されていないかを確認するために、全てのログ・ステートメントを調査する
シナリオ# 1： 管理者用エンドポイントの公開
モバイルエンドポイントへのテストの一環として、開発者は管理者向けダッシュボードを表示する隠しインターフェースをモバイルアプリ内に含めました。このダッシュボードは、バックエンドAPIサーバを経由して管理者情報にアクセスしていました。正式公開用のコード内に、開発者はこのダッシュボードを表示するコードを含めませんでした。しかしながら、バックエンドの管理者用APIにアクセス可能なコードは含まれていました。攻撃者は、文字列テーブルのバイナリ解析を実施し、管理者向けRESTエンドポイントのハードコードされたURLを見つけました。次に攻撃者は「curl」を使用し、バックエンドの管理者機能を実行しました。
開発者は、ネイティブインターフェースから直接アクセスできないコードを含め全ての余計なコードを削除すべきです。
シナリオ #2： 設定ファイル内のデバッグフラグ
攻撃者はローカルアプリ内の .properties ファイルに「debug=true」を手動で追記しました。起動時に、アプリケーションは、攻撃者がバックエンドシステムを理解しうる過剰な記述をログファイルに出力します。そのログ出力から、攻撃者はバックエンドシステム内の脆弱性を見つけます。
開発者はモバイルアプリのプロダクションビルドで「デバッグモード」が有効化されないようにしなければなりません。