OWASP Mobile Top 10 解説 (2024 RC版準拠)

OWASP (Open Web Application Security Project) は、ソフトウェアのセキュリティ向上を目指すオープンなコミュニティです。OWASP Mobile Top 10 は、モバイルアプリケーションにおける最も重大なセキュリティリスクを特定し、ランク付けしたものです。開発者やセキュリティ担当者がモバイルアプリの安全性を確保するための重要な指針となります。

最後に公式リストが発表されたのは2016年ですが、モバイルを取り巻く環境の変化は速く、2024年にはリリース候補 (Release Candidate, RC) 版が公開されました。このブログでは、このOWASP Mobile Top 10 2024 RCに基づき、各リスクについて解説していきます。モバイルアプリ開発に関わるすべての人にとって必読の内容です！

なぜOWASP Mobile Top 10が重要なのでしょうか？

• モバイルデバイスは個人情報や機密データへのアクセスポイントであり、攻撃者にとって魅力的なターゲットです。
• 脆弱性のあるアプリは、ユーザーのデータ漏洩、金銭的損失、なりすまし、マルウェア感染などの深刻な被害を引き起こす可能性があります。
• 開発者は、これらのリスクを理解し、設計・開発段階から適切な対策を講じることが不可欠です。

これは、モバイルアプリがユーザー認証情報（ユーザー名、パスワード）、APIキー、トークンなどを不適切に取り扱うリスクです。非常に一般的でありながら、深刻な被害につながる可能性があります。

主な問題点

• ハードコードされたクレデンシャル: ソースコードや設定ファイル内にパスワードやAPIキーが直接書き込まれている。リバースエンジニアリングによって容易に発見されてしまいます。
• 安全でないクレデンシャルの保存: 認証情報を平文や弱い暗号化でデバイス上に保存している。デバイスへの物理アクセスやマルウェアによって盗まれる可能性があります。iOS Keychainのようなセキュアなストレージを利用しない場合などが該当します。
• 安全でないクレデンシャルの送信: 認証情報を暗号化されていない通信（HTTPなど）で送信している。中間者攻撃（MitM）によって盗聴される危険があります。
• 弱いパスワードポリシー: パスワードの最小長や複雑性（文字種など）の要件が緩い。ブルートフォース攻撃や辞書攻撃で容易に破られてしまいます。
• 不適切なセッション管理: セッションタイムアウトが長すぎる、セッショントークンが推測しやすいなど。セッションハイジャックのリスクがあります。

攻撃シナリオ例

攻撃者はアプリをリバースエンジニアリングしてハードコードされたAPIキーを発見し、それを使ってバックエンドシステムに不正アクセスし、大量のユーザーデータを盗み出します。また、公共Wi-Fiなどで暗号化されずに送信されるログイン情報を盗聴し、ユーザーになりすまして不正操作を行うことも考えられます。2014年には、スターバックスのモバイルアプリの一部バージョンがユーザー認証情報を平文でデバイスに保存していた事例が報告されています。

対策のポイント

• クレデンシャルをコード内にハードコードしない。
• OSが提供するセキュアなストレージ（iOS Keychain, Android Keystore）を利用する。
• 通信は必ずHTTPS (TLS) を使用し、証明書検証を正しく行う。
• 強力なパスワードポリシーを適用し、多要素認証 (MFA) の導入を検討する。
• 安全なセッション管理手法を実装する。
• APIキーなどの機密情報はサーバー側で管理し、直接クライアントに埋め込まない。

現代のモバイルアプリ開発では、サードパーティ製のライブラリ、SDK、フレームワーク、サービスなどを利用するのが一般的です。サプライチェーンセキュリティの欠陥は、これらの外部コンポーネントや開発・配布プロセスに存在する脆弱性を指します。2024年版で新たに追加されたリスク項目であり、近年の複雑化する開発環境を反映しています。

主な問題点

• 脆弱なサードパーティコンポーネント: 利用しているライブラリやSDKに既知の脆弱性が存在する。
• 悪意のあるコードの混入: 開発プロセス中やビルド環境で、悪意のある内部関係者や攻撃者によって不正なコードが注入される。
• 不適切なコンポーネントの検証: 利用するライブラリやSDKの信頼性や安全性を十分に検証せずに導入してしまう。
• 安全でない配布プロセス: アプリの署名鍵が漏洩したり、改ざんされたアプリが公式ストア以外で配布される。
• 不十分なテストと検証: サプライチェーン全体を通じたセキュリティテストや検証が不足している。

攻撃シナリオ例

攻撃者が人気のライブラリに悪意のあるコードを混入させ、そのライブラリを利用している多数のアプリを通じてユーザーデータを盗み出す（例: XcodeGhost事件）。あるいは、開発者のビルド環境に侵入し、正規アプリのリリースプロセス中にマルウェアを注入し、署名して公式ストアで配布する。ユーザーが感染したアプリをインストールすると、認証情報や機密データが盗まれます。

対策のポイント

• 信頼できるソースからのみコンポーネントを入手し、定期的に脆弱性スキャンを実施する。
• ソフトウェア部品表 (SBOM: Software Bill of Materials) を管理し、利用しているコンポーネントを把握する。
• ビルド環境やCI/CDパイプラインのセキュリティを確保する。
• アプリ署名鍵を厳重に管理する。
• サードパーティコンポーネントのセキュリティ評価を行うプロセスを導入する。
• 開発者へのセキュリティ教育を徹底する。

認証 (Authentication) は「ユーザーが誰であるか」を確認するプロセス、認可 (Authorization) は「そのユーザーが何をする権限を持っているか」を制御するプロセスです。これらの制御が不十分だと、不正アクセスや権限昇格につながります。OWASP Top 10では常に上位にランクインする重要なリスクです。

主な問題点

• 弱い認証メカニズム: M1とも関連しますが、パスワードポリシーが甘い、MFAがない、ブルートフォース対策が不十分など。
• 不適切なセッション管理: セッショントークンが推測可能、有効期限が長すぎる、ログアウト時に無効化されないなど。セッションハイジャックを招きます。
• 認証回避: 特定の画面や機能を、認証を経ずにアクセスできてしまう。Androidアプリでインテントを使ってログイン画面を迂回するなどの手法があります。
• 不十分な認可制御 (権限昇格): 一般ユーザーが管理者機能を使えたり、他のユーザーの情報にアクセスできてしまう（IDOR/BOLA: Insecure Direct Object Reference / Broken Object Level Authorization）。
• クライアント側での認可決定: 権限チェックをサーバー側ではなく、改ざん可能なクライアント側で行っている。

攻撃シナリオ例

攻撃者が他のデータ漏洩で入手した認証情報リストを使って、クレデンシャルスタッフィング攻撃を仕掛け、弱い認証システムを突破してアカウントを乗っ取る。あるいは、ログイン後にAPIリクエストのパラメータ（例: ユーザーID）を改ざんし、他のユーザーの情報にアクセスする（IDOR/BOLA）。2014年のスターバックスアプリの事例や、ShopifyのKitアプリにおけるBOLA脆弱性の報告（2024年頃）などがあります。

対策のポイント

• 強力な認証方式（MFA、生体認証など）を導入する。
• 安全なセッション管理（短命なトークン、適切な失効処理）を行う。
• 認証・認可制御は必ずサーバーサイドで実施し、クライアント側のチェックを信用しない。
• アクセス制御を徹底し、ユーザーのロールや権限に基づいてアクセスできるリソースや機能を厳密に制限する（最小権限の原則）。
• IDOR/BOLA対策として、リソースへのアクセス時に所有権や権限を必ずサーバー側で検証する。
• 隠しエンドポイントなども含め、全てのAPIエンドポイントで認証・認可チェックを行う。

これは、ユーザーからの入力（Input）や、アプリが表示・処理するデータ（Output）を適切に検証・無害化（サニタイズ）しないことによるリスクです。「ユーザー入力を信用しない」はセキュリティの鉄則ですが、これが守られていない場合に発生します。

主な問題点

• 不十分な入力値検証: ユーザーが入力したデータ（検索クエリ、フォーム入力、APIパラメータなど）を検証せずに処理してしまう。
• 不十分な出力値検証/サニタイズ: ユーザーが生成したコンテンツや外部から取得したデータを、無害化せずに表示・処理してしまう。
• コンテキストに応じた検証の欠如: データが利用される文脈（SQLクエリ、HTML、コマンドなど）を考慮せずに検証・エスケープを行っている。

攻撃シナリオ例

攻撃者が入力フィールドにSQLコード（例: ' OR '1'='1）を入力し、入力値検証が不十分な場合、データベースへの不正アクセス（SQLインジェクション）が可能になります。また、入力フィールドにJavaScriptコード（例: <script>alert('XSS')</script>）を入力し、出力時のサニタイズが不十分な場合、他のユーザーのブラウザでスクリプトが実行され、セッションハイジャックや情報窃取（クロスサイトスクリプティング, XSS）につながります。コマンドインジェクション、パス・トラバーサルなどもこのカテゴリに含まれます。過去には、Heartland Payment Systems (2009年) の大規模な情報漏洩がSQLインジェクションによって引き起こされました。

対策のポイント

• 入力値は常にサーバーサイドで検証する（クライアント側の検証は補助的に）。
• 許可リスト（ホワイトリスト）形式での検証を基本とする（許可された文字種、形式、長さのみ受け付ける）。
• データの型、形式、範囲を厳密にチェックする。
• 出力するデータは、表示されるコンテキストに応じて適切にエスケープ（HTMLエスケープ、URLエンコードなど）する。
• パラメータ化されたクエリ（プリペアドステートメント）を使用してSQLインジェクションを防ぐ。
• 信頼できないデータをOSコマンドやファイルパスとして使用しない。
• Web Application Firewall (WAF) の導入も有効な対策の一つ。

モバイルアプリがサーバーや他のサービスと通信する際に、データが暗号化されていなかったり、暗号化が不十分だったりするリスクです。これにより、通信経路上でデータが盗聴されたり、改ざんされたりする可能性があります。

主な問題点

• 暗号化されていない通信: HTTPなど、暗号化されていないプロトコルで機密情報を送受信している。
• 弱い暗号化プロトコル/暗号スイートの使用: 古いバージョンのSSL/TLS（例: SSLv3, TLS1.0/1.1）や、脆弱な暗号アルゴリズム（例: RC4, 3DES）を使用している。
• 不適切な証明書検証: サーバー証明書の有効性（有効期限、発行元、ホスト名）を検証しない、または検証を迂回している。自己署名証明書を安易に受け入れている。
• 機密情報の漏洩: 本来暗号化すべき認証情報、個人情報、セッショントークンなどを平文で送信している。
• 代替チャネルでの機密情報送信: SMSやプッシュ通知など、暗号化が保証されないチャネルで機密情報を送信している。

攻撃シナリオ例

攻撃者が公共Wi-Fiなどで中間者攻撃（Man-in-the-Middle, MitM）を行い、HTTP通信を盗聴してログイン情報を窃取する。あるいは、偽の証明書を使ってHTTPS通信に割り込み、通信内容を解読・改ざんする（証明書検証が不適切な場合）。過去には、Heartbleed脆弱性 (2014年) により、多くのサーバーでTLS通信の秘密鍵が漏洩する可能性がありました。また、Klarnaの金融アプリ (2022年) では、不適切なHTTPS利用によりユーザー情報が他のユーザーに見えてしまうインシデントが発生しました。

対策のポイント

• 全ての通信でHTTPS (TLS 1.2以上を推奨) を強制する。
• 強力な暗号スイートのみを使用し、脆弱なものは無効化する。
• サーバー証明書の検証を厳格に行う（OS標準の検証機能を利用）。
• 証明書ピニング（Certificate Pinning）の導入を検討する（ただし運用に注意が必要）。
• 機密情報はペイロード内でも追加で暗号化することを検討する。
• SMSやプッシュ通知では機密情報を直接送信しない。

モバイルアプリがユーザーの個人情報 (PII: Personally Identifiable Information) や機密データを適切に保護できていないリスクです。これには、データの収集、保存、利用、送信、削除に関する管理策の不備が含まれます。GDPRやCCPAなどのプライバシー規制の強化に伴い、重要性が増しています。

主な問題点

• 過剰なデータ収集: アプリの機能に必要ない個人情報を収集している。
• 不十分な同意取得: ユーザーから明確かつ具体的な同意を得ずにデータを収集・利用している。
• 安全でないデータ保存 (M9と関連): 個人情報を暗号化せずに保存したり、アクセス制御が不十分な場所に保存している。
• 安全でないデータ送信 (M5と関連): 個人情報を暗号化せずに送信している。
• 不適切なデータ共有: ユーザーの同意なく、個人情報をサードパーティと共有している。
• データの匿名化/仮名化の不備: データを統計処理などで利用する際に、個人を特定できないようにする処理が不十分。
• データ削除要求への未対応: ユーザーからのデータ削除要求に対応できる仕組みがない、または対応が不十分。

攻撃シナリオ例

アプリが収集した位置情報や閲覧履歴などのPIIが、不適切なアクセス制御や暗号化の不備により漏洩し、ユーザーのプライバシーが侵害される。あるいは、ユーザーの同意なく収集されたデータがマーケティング目的で第三者に販売される。eBay (2014年) やMarriott (Starwood) (2018年) の大規模な情報漏洩事件では、顧客の個人情報が多数流出しました。

対策のポイント

• プライバシー・バイ・デザインの原則に基づき、設計段階からプライバシー保護を考慮する。
• 収集するデータは必要最小限に留める（データ最小化の原則）。
• データ収集・利用目的を明確にし、ユーザーから適切な同意を得る。
• 個人情報は強力な暗号化とアクセス制御で保護する。
• データ送信時はTLSを使用する。
• プライバシーポリシーを明確かつ分かりやすく記述し、公開する。
• 関連するプライバシー法規制（GDPRなど）を遵守する。
• 定期的なプライバシー影響評価（PIA）を実施する。

これは、モバイルアプリのコンパイル済みコード（バイナリ）が、リバースエンジニアリング（解析）や改ざん（Tampering）に対して十分に保護されていないリスクです。2016年版の「Code Tampering」と「Reverse Engineering」を統合した項目です。

主な問題点

• 難読化の欠如: コードが難読化されておらず、容易に解析されてロジックやアルゴリズムが理解されてしまう。
• デバッグ情報の残留: リリースビルドにデバッグ情報やシンボル情報が残っており、解析を助けてしまう。
• 改ざん検知機能の欠如: アプリのコードやリソースが改ざんされたことを検知する仕組みがない。
• ルート化/ジェイルブレイク検知の欠如: 不正な権限昇格が行われたデバイスでの実行を検知・防止する仕組みがない。
• エミュレータ/デバッガ検知の欠如: 解析目的で利用されるエミュレータやデバッガ環境での実行を検知・防止する仕組みがない。
• 機密情報のハードコーディング (M1と関連): APIキーや暗号鍵などがバイナリ内に直接埋め込まれている。

攻撃シナリオ例

攻撃者がアプリのバイナリをリバースエンジニアリングし、課金処理やライセンス認証のロジックを解析・改ざんして、有料機能を無料で利用できるようにする（クラッキング）。あるいは、バイナリ内にハードコードされたAPIキーを発見し、不正に利用する。また、正規アプリにマルウェアを注入して再パッケージ化し、非公式ストアなどで配布してユーザーを感染させる。

対策のポイント

• コード難読化ツール（ProGuard, R8, SwiftObfuscatorなど）を適用する。
• リリースビルドからはデバッグ情報やログ出力を削除する。
• 改ざん検知（コード署名検証、チェックサム）の仕組みを導入する。
• ルート化/ジェイルブレイク検知機能を実装する。
• アンチデバッグ、アンチエミュレーション技術を導入する。
• 重要なロジックや機密情報は可能な限りサーバーサイドに置く。
• バイナリ内に機密情報を埋め込まない。やむを得ない場合は、難読化や暗号化を施す（ただし完全ではない）。
• Runtime Application Self-Protection (RASP) ソリューションの導入を検討する。

これは、モバイルアプリ本体、OS、プラットフォーム、あるいは関連するバックエンドサービスなどのセキュリティ設定が不適切であることに起因するリスクです。開発プロセス中の人的ミス、知識不足、デフォルト設定の放置などが原因となります。

主な問題点

• 安全でないデフォルト設定: フレームワークやプラットフォームのデフォルト設定が安全でないまま利用されている。
• 不要な機能の有効化: デバッグモードやテスト用機能がリリースビルドで有効になっている。
• 過剰な権限設定: アプリが必要以上のOS権限（パーミッション）を要求している。ファイルパーミッションが不適切（World Readable/Writable）。
• エラーメッセージによる情報漏洩: 詳細すぎるエラーメッセージがユーザーに表示され、内部情報が漏洩する。
• クラウド設定の不備: アプリが利用するクラウドストレージ（S3など）やデータベースのアクセス権限設定が不適切。
• 不適切なHTTPヘッダー設定: セキュリティ関連のHTTPヘッダー（Strict-Transport-Security, Content-Security-Policyなど）が設定されていない、または設定が不適切。
• バックアップ設定の不備: Androidの自動バックアップ機能により、機密情報を含むアプリデータが意図せずバックアップされる。

攻撃シナリオ例

リリースビルドでデバッグモードが有効になっており、攻撃者がこれを利用してアプリ内部の情報を取得したり、動作を改変したりする。あるいは、Androidアプリで `exported=”true”` に設定されたコンポーネント（Activity, Service, BroadcastReceiver, ContentProvider）が意図せず外部アプリからアクセス可能になっており、不正利用される。 Equifax (2017年) の情報漏洩事件は、Webフレームワーク (Apache Struts) の設定不備が一因でした。

対策のポイント

• 安全な設定を標準とし、デフォルト設定に頼らない。
• 最小権限の原則に従い、アプリが必要とする最低限の権限のみを要求・設定する。
• リリースビルドではデバッグ機能や不要な機能を無効化する。
• エラーハンドリングを適切に行い、ユーザーには必要最小限の情報のみを表示する。
• クラウドサービスやバックエンドの設定を定期的にレビューし、ベストプラクティスに従う。
• セキュリティ関連のHTTPヘッダーを適切に設定する。
• Androidでは `allowBackup=”false”` を適切に設定する。
• 設定ファイルやマニフェストファイルを定期的に監査する。

これは、モバイルデバイス上に保存されるデータ（認証情報、個人情報、セッショントークン、アプリ設定など）が適切に保護されていないリスクです。デバイスの紛失・盗難、マルウェア感染、あるいは他のアプリからの不正アクセスによって、機密情報が漏洩する可能性があります。2016年版ではM2でしたが、順位は下がったものの依然として重要なリスクです。

主な問題点

• 暗号化されていない保存: 機密データを平文でファイル（SharedPreferences, UserDefaults, SQLiteデータベース, plistファイルなど）に保存している。
• 弱い暗号化: 脆弱な暗号化アルゴリズムや、ハードコードされた暗号鍵（M1, M10とも関連）を使用している。
• 不適切な保存場所: SDカードなど、他のアプリからアクセス可能な場所に機密データを保存している。
• 不適切なアクセス制御: ファイルパーミッションが緩すぎる。Content Providerの設定が不適切で、他のアプリからデータにアクセス可能になっている。
• キャッシュやログへの機密情報混入: 一時ファイルやデバッグログに意図せず機密情報が書き込まれてしまう。
• キーボードキャッシュ: OSのキーボードキャッシュにパスワードなどの入力情報が残ってしまう。
• バックアップからの漏洩 (M8と関連): 暗号化されていないバックアップに機密情報が含まれる。

攻撃シナリオ例

攻撃者が盗難または紛失したデバイスを入手し、ファイルシステムを直接読み取って、平文で保存されているパスワードやAPIキーを抽出する。あるいは、悪意のあるアプリが、SDカードや不適切に設定されたContent Providerを経由して、他のアプリの機密データにアクセスする。

対策のポイント

• 機密データはデバイス上に保存しないのが最も安全。やむを得ず保存する場合は最小限に留める。
• OSが提供するセキュアなストレージ（iOS Keychain, Android Keystore）を積極的に利用する。
• ファイルシステムに保存する場合は、強力な暗号化（AESなど）を適用する。暗号鍵の管理には特に注意する（Keystore/Keychainを利用）。
• アプリの内部ストレージ（他のアプリからアクセスできない領域）にデータを保存する。
• ファイルやディレクトリのパーミッションを適切に設定する。
• ログやキャッシュに機密情報を含めないように注意する。
• パスワード入力フィールドなどではキーボードキャッシュを無効化する設定を行う。
• `allowBackup=”false”` を設定するか、バックアップ対象データを注意深く選択する。

これは、暗号技術（アルゴリズム、プロトコル、鍵管理）の選択や実装が不適切であるために、データの機密性や完全性が損なわれるリスクです。暗号化を行っているつもりでも、その方法が間違っていると意味がありません。

主な問題点

• 脆弱な/非推奨のアルゴリズムの使用: DES, 3DES, RC2, MD5, SHA-1 など、現在では安全でないとされる暗号アルゴリズムやハッシュ関数を使用している。
• 不適切な暗号モード: ECBモードなど、暗号利用モードの選択が不適切で、パターンが推測されるなどの脆弱性がある。
• 不十分な鍵長: 暗号鍵の長さが短すぎて、ブルートフォース攻撃で解読される可能性がある。
• 不適切な鍵管理:
  • 暗号鍵をハードコードしている (M1, M7とも関連)。
  • 暗号鍵を安全でない場所に保存している (M9と関連)。
  • 暗号鍵の生成方法が安全でない（予測可能な乱数など）。
  • 暗号鍵を定期的に更新していない。
• 初期化ベクトル (IV) / ソルトの不適切な使用: IVを再利用したり、ソルトを使用しなかったりする。
• 独自の暗号プロトコルの作成・使用: 実績のある標準的なプロトコルを使わず、独自に設計した安全性の低いプロトコルを使用している。
• 暗号化すべきデータの未暗号化 (M5, M9とも関連): 本来暗号化すべき機密データを暗号化していない。

攻撃シナリオ例

アプリが脆弱なMD5アルゴリズムでパスワードハッシュを保存しており、攻撃者がレインボーテーブルなどを使って元のパスワードを容易に割り出す。あるいは、暗号鍵がソースコードにハードコードされており、リバースエンジニアリングによって鍵を入手した攻撃者が、暗号化されたデータを復号する。2014年のHeartbleed脆弱性も、TLS/SSLという暗号プロトコルの実装上の欠陥でした。

対策のポイント

• 広く受け入れられている最新かつ強力な暗号アルゴリズム（AES, RSA, ECDSAなど）とハッシュ関数（SHA-256以上）を使用する。
• 推奨される暗号モード（GCM, CCMなど）を使用する。
• 十分な長さの暗号鍵を使用する（アルゴリズムの推奨に従う）。
• 暗号鍵はOS提供のセキュアな機構（Keychain, Keystore）で管理・保護する。ハードコードは絶対に避ける。
• 鍵生成には暗号論的に安全な乱数生成器を使用する。
• IVは暗号化ごとにユニークな値を生成し、ソルトは適切に使用する。
• 独自の暗号方式を設計・実装しない。標準ライブラリや実績のあるライブラリを利用する。
• 暗号化の専門知識を持つ担当者がレビューを行うか、外部の専門家による診断を受ける。

OWASP Mobile Top 10 2024 RCは、現代のモバイルアプリが直面する主要なセキュリティリスクを網羅しています。これらのリスクは相互に関連していることも多く、多層的な防御アプローチが不可欠です。

安全なモバイルアプリを開発・提供するためには、開発の初期段階からセキュリティを考慮に入れ（セキュリティ・バイ・デザイン）、コードレビュー、脆弱性診断、ペネトレーションテストなどを継続的に実施することが重要です。

この解説が、皆さんのモバイルアプリ開発におけるセキュリティ意識の向上と、具体的な対策の一助となれば幸いです。安全なモバイル体験をユーザーに届けましょう！ 😊