OWASP Mobile Top 10 2024 – モバイルアプリのセキュリティにおける最も重大な脆弱性への対処ガイド

開発者が作成するコードやスクリプトでは、さまざまなリソースにアクセスしたり、他のアプリケーションやツールと連携したりするために、認証情報（SSHキーやAPIトークンなど）やパスワードが必要になることがよくあります。
開発作業を効率化するために、開発者がコード内にこうした機密情報を直接記述してしまうケースが少なくありません。このように認証情報がハードコーディングされると、コードにアクセスできる誰もが機密情報を閲覧できてしまいます。

認証情報を安全に管理するためには、ハードコーディングを避け、以下のような管理対策を講じる必要があります。

- 適切な対策

認証情報は送信時に暗号化する。
ユーザーの認証情報をデバイスに保存しない。代わりに、安全で失効可能なアクセス トークンの使用を検討する。
強力なユーザー認証プロトコルを実装する。
使用しているAPIキーやトークンは定期的に更新・ローテーションする。

2. 不十分なサプライチェーンセキュリティ

 モバイルアプリのサプライチェーンに脆弱性があると、攻撃者がコードベースに悪意のあるコードを挿入したり、ビルドプロセス中にコードを改ざんしてバックドアやスパイウェア、その他のマルウェアを組み込んだりする可能性があります。これにより、データの窃取、ユーザーの監視、モバイルデバイスの制御が可能になります。

特に、サードパーティが開発したモバイルアプリや、サードパーティ製のライブラリやコンポーネントに依存する場合に、こうした脅威が発生しやすくなります。
アプリ開発者がサードパーティ製コンポーネントを適切に検査・更新しない場合、これらの攻撃に対して脆弱になります。

- 適切な対策

• モバイルアプリの開発ライフサイクル全体にわたり、安全なコーディング手法、コードレビュー、テストを実施し、脆弱性を特定・軽減する。
• 安全なアプリ署名および配布プロセスを確立し、攻撃者による悪意あるコードの署名や配布を防止する。
• 信頼できる検証済みのサードパーティライブラリやコンポーネントのみを使用し、脆弱性のリスクを低減する。
• アプリの更新・パッチ・リリースに関するセキュリティ管理を確立し、攻撃者によるアプリの脆弱性悪用を防ぐ。
• セキュリティテストやスキャン、その他の手法を通じてサプライチェーンのセキュリティインシデントを監視・検知し、インシデントに迅速に対応できる体制を整える。

3. 安全でない認証／認可

 攻撃者は、認証や認可システムの脆弱性を悪用し、モバイルアプリの認証を偽装またはバイパスする可能性があります。認証システムに欠陥があったり、そもそも実装されていなかったりすると、攻撃者はバックエンドサーバーを介して匿名でモバイル機能を実行することができます。
ユーザーの本人確認ができなければ、攻撃元の特定も困難になり、直接的なリスクにさらされることになります。

モバイルアプリのセキュリティを評価するには、「認証」と「認可」の違いを理解することが重要です。
認証は個人を特定するためのものであり、認可は特定の行為に必要な権限を持っているかを確認するものです。

以下は、モバイルアプリにおける不適切な認証および認可の例です。

- 不適切な認証

匿名でのバックエンドAPI実行
パスワードや共有シークレットをローカルに保存
弱いパスワードポリシー
FaceIDやTouchIDなどの機能への依存

- 不適切な認可

不適切な直接オブジェクト参照（IDOR）脆弱性の存在
隠されたエンドポイントの存在
ユーザーのロールや権限情報をバックエンドシステムに送信する仕組み

- 適切な対策

Webアプリからモバイルアプリへ移行する際は、認証要件を適切に整合させる。
認証リクエストは、可能な限りサーバーサイドで処理する。
クライアント側にデータを保存する必要がある場合は、ユーザーログイン情報から安全に導出された暗号鍵を使用してデータを暗号化する。
ユーザーには、デバイス上にパスワードを保存しないよう推奨する。
認証・認可の制御はサーバー側で強化する。
オフライン環境でローカル認証や認可チェックを行う場合は、不正なコード改ざんを検知するためにローカル整合性チェックを実施する。
バックエンドシステム側で、認証済みユーザーの権限や承認を独立して検証する。また、すべてのクライアント側認証はバイパスされる可能性があるものと想定し、可能な限りサーバーサイドでの認証・認可を強化する。

4. 不十分な入出力バリデーション

モバイルアプリがユーザー入力やネットワークデータなどの外部ソースからのデータを適切に検証しない場合、SQLインジェクション、コマンドインジェクション、XSS攻撃など、モバイル環境に特化した攻撃に脆弱になる可能性があります。攻撃者はシステムにアクセスし、アプリ内で不正なコードを実行したり、許可なくデータを抽出したりすることができ、アプリ機能やモバイルシステム全体を制御する可能性があります。

- 適切な対策

5. 安全でない通信

モバイルアプリは、1つ以上のリモートサーバーとデータを交換します。通常、モバイルデバイスはTCP/IP、WiFi、Bluetooth/Bluetooth-LE、NFC、オーディオ、赤外線、GSM、3G、SMSなど、さまざまな通信技術を使用してデータを送信します。しかし、ローカルネットワークが侵害されたり、ネットワークデバイスやモバイルデバイスに悪意のあるコードが挿入されたりすると、アカウントの乗っ取り、個人情報の盗難、個人を特定できる情報（PII）の漏洩など、さまざまな被害が発生する可能性があります。

特に注目すべき特徴は、デバイス間で交換される機密データ（暗号鍵、パスワード、個人ユーザー情報、アカウント詳細、セッショントークン、文書、メタデータ、バイナリファイルなど）の交換です。このような場合、一部のデータが傍受されるリスクがあります。

- 適切な対策

• モバイルアプリのバックエンドAPIまたはWebサービスのデータ送信チャネルにSSL/TLSを適用します。アプリケーションがブラウザ/WebKitを介してルーチンを実行する際、第三者の分析会社やソーシャルネットワークなどの外部エンティティをSSLバージョンを使用して記述します。混在SSLセッションは、ユーザーのセッションIDを露出させる可能性があるため避けます。
• 適切な鍵長を持つ業界標準の暗号化製品を使用します。信頼できるCAプロバイダに署名された証明書を使用し、無効な証明書（自己署名、期限切れ、信頼されていないルート、取り消し、誤ったホストなど）は受け入れないようにします。
• 敏感なデータを代替チャネル（例：SMS、MMS、通知など）で送信しないようにします。可能であれば、SSLチャネル経由で敏感なデータを送信する前に追加の暗号化レイヤーを適用します。将来のSSL実装で脆弱性が発見された場合、暗号化されたデータは機密性違反に対する二次的な防御となります。開発サイクル中は、信頼できない証明書を許可するようにSSL検証方法を再定義するのではなく、自己署名証明書またはローカル開発認証局（CA）を使用します。

6. 不十分なプライバシー管理

個人を特定できる情報（PII）の保護は、名前、住所、クレジットカード情報、メールアドレス、IPアドレス、さらには健康、宗教、性的嗜好、政治的意見に関する情報を守ることを含みます。攻撃者はこの情報を悪用して、被害者になりすました詐欺を行ったり、支払いデータを不正に使用したり、敏感な情報で脅迫したり、重要な被害者データを破壊または操作したりすることがあります。PIIを取得するためには、攻撃者はまずネットワークやファイルシステム、ログアクセスなど他のセキュリティレベルを突破する必要があります。

- 適切な対策

• 処理されるPIIを最小限に抑える。
• 必要不可欠でない限り、PIIを保存したり送信したりしない。
• 重要なデータは、適切な認証および認可によって保護する。