モバイルアプリにおけるCode Injection — 概要、攻撃の種類、保護

Code Injectionとは？

Code Injectionは、攻撃者が信頼できない入力データを介してアプリケーションに実行可能コードを注入する攻撃のクラスです。モバイルアプリケーションでは、入力フィールド、ディープリンク、プッシュ通知、QRコード、ファイル交換を介した攻撃が可能です。

OSレベルの攻撃とは異なり、Code Injectionはアプリケーション自身のコードの論理エラー（エスケープ処理の欠如、安全でない文字列連結、外部データソースへの信頼）を悪用します。Positive Technologies（2025）のレポートによると、金融セクターのモバイルアプリケーションにおける全脆弱性の23%がインジェクションです。

Code Injectionの主な危険性は完全なデータ漏洩です。攻撃者はデータベース、デバイスのファイルシステム、他のユーザーのアカウントにアクセスできます。決済データや医療情報を扱うモバイルアプリケーションでは、結果は重大になる可能性があります。

開発者はインジェクションの種類を理解し、データ入力から表示、保存までのすべてのレベルで保護メカニズムを適用する必要があります。最新のフレームワークは組み込みのセキュリティツールを提供していますが、それらを使用するには意識的なアプローチが必要です。

モバイルアプリにおけるCode Injectionの主な種類

Code Injectionの分類には、モバイル開発のコンテキストにおける3つの主要な攻撃タイプが含まれます。各タイプはアプリケーションの異なるコンポーネントを悪用し、特定の保護方法を必要とします。

モバイルアプリにおけるSQL Injection

SQL Injection（SQLi）は、ローカルまたはリモートデータベースへのクエリパラメータを介した悪意のあるSQLコードの注入です。モバイルアプリケーションでは、デバイス上のSQLiteを安全でない方法で使用したり、文字列連結を使用してREST APIへのHTTPリクエストを構築したりする際に脆弱性が発生します。

典型的な攻撃ベクトルは、検索またはフィルタフィールドで、その値がSQLクエリに直接代入されるものです。開発者がパラメータ化クエリの代わりに生の連結を使用する場合、攻撃者は1' OR '1'='1のような文字列を渡すことができます。OWASP Mobile Top 10（2024）によると、SQL Injectionは安全でないデータストレージカテゴリにおいて、モバイルアプリケーションで2番目に頻繁な重大脆弱性であり続けています。

SQLiからの保護は3つのレベルで構築されます：パラメータ化クエリの使用（JavaのPreparedStatement、AndroidのbindArgs付きrawQuery）、クライアント側とサーバー側での入力検証、最小限のデータベース権限。

WebViewにおけるCross-Site Scripting（XSS）

モバイルアプリケーションにおけるXSS攻撃は、HTMLコンテンツを表示する組み込みブラウザであるWebViewコンポーネントを標的にします。アプリケーションがサニタイズなしでWebViewに外部ソースからデータをロードする場合、攻撃者はアプリケーションコンテキストで実行されるJavaScriptコードを注入できます。

XSSには2つのサブタイプがあります：Stored XSS — 悪意のあるスクリプトがサーバーに保存され、ページが表示されるたびに実行されます。Reflected XSS — コードがURLまたはPOSTパラメータを介して渡され、1回だけ実行されます。モバイルアプリケーションでは、コメント、レビュー、またはWebViewで他のユーザーに表示されるユーザーコンテンツを介したStored XSSが特に危険です。

保護には、不要な場合はWebViewでJavaScriptを無効にすること、Content Security Policy（CSP）を使用すること、Androidの場合はJsoup、iOSの場合はSwiftSoupなどのライブラリを介してHTMLコンテンツをサニタイズすることが含まれます。

IntentおよびShellを介したCommand Injection

Command Injectionは、Runtime.exec()、ProcessBuilder、またはNSTaskへのサニタイズされていない呼び出しを介して、デバイス上でシステムコマンドを実行する攻撃です。モバイルアプリケーションでは、アプリケーションがユーザーデータをシェルコマンドやアクション付きIntentに渡す場合に攻撃が可能です。

最も脆弱な領域は、ファイル変換機能、メディア処理（ffmpeg、ImageMagick）、サードパーティライブラリのインストールです。攻撃者はパイプまたはリダイレクト文字を含むコマンドを渡すことができ、デバイス上で任意のコードを実行します。Androidはサンドボックスを通じてシェルアクセスを部分的に制限していますが、ルートアクセスやPrivEscエクスプロイトを持つアプリケーションは侵害される可能性があります。

推奨される保護は、ユーザーデータ処理のためのRuntime.exec()の完全な拒否、安全なAPIを持つライブラリの使用、外部プロセスの厳格な分離です。

AndroidおよびiOSでのコードインジェクションの仕組み

Code Injectionのメカニズムは、アーキテクチャの違いによりAndroidとiOSプラットフォームで異なります。Androidでは、インジェクションはしばしばIntent（アプリケーションコンポーネント間で渡されるシステムメッセージ）に関連しています。攻撃者はSQLコードやシェルコマンドを含む追加データを持つ悪意のあるIntentを送信できます。

iOSでは、攻撃はより頻繁にプロセス間通信（XPC）メカニズム、ユニバーサルリンク、URLスキーム処理を介して発生します。検証なしで外部ソースからのデータを受け入れるアプリケーションは、インジェクションに対して脆弱になります。Apple Security Research（2025）によると、iOSアプリケーションの脆弱性の約12%は、不十分な入力データサニタイズに関連しています。

両プラットフォームに共通するベクトルは、ローカルストレージ（SQLite、Realm、UserDefaults）を介した攻撃です。悪意のあるアプリケーションが共有ディレクトリにデータを書き込める場合、読み取り時にターゲットアプリケーションによって実行されるコードを注入できます。

典型的な攻撃プロセスには3つの段階があります：偵察（フォーム、ディープリンク、ファイルなどのアプリケーションの入力ポイントの分析）、注入（見つかった入力ポイントを介した悪意のあるペイロードの配信）、悪用（データや機能へのアクセスを得るためのインジェクションの実行）。このサイクルを理解することで、開発者は各段階で保護を設計できます。

コード例：脆弱な実装と安全な実装

Android向けKotlinとiOS向けSwiftにおけるCode Injectionの具体的な例を見てみましょう。各例は脆弱なパターンとその安全な代替案を示しています。

SQL Injection：Kotlinの脆弱なコード

最初の例は、ユーザー入力によるクエリ文字列の直接連結です。userInput = "1' OR '1'='1"という値の場合、クエリは1行ではなくテーブルのすべての行を返します。

// 脆弱: 文字列の連結
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// 安全: パラメータ化クエリ
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

WebViewでのXSS保護：iOS向けSwift

2番目の例は、WKWebViewでのユーザーHTMLコンテンツの誤った読み込みと正しい読み込みを示しています。SwiftSoupを使用すると、レンダリング前に悪意のあるスクリプトを削除できます。

// 脆弱: 直接的なHTML読み込み
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// 安全: SwiftSoupによるサニタイズ
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection：Kotlinでのシェル攻撃からの保護

3番目の例は、ユーザー引数でRuntime.exec()を呼び出す危険性と、固定APIを持つライブラリを介した安全な代替案です。

// 脆弱: ユーザー入力によるシェルコマンド
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// 安全: 引数の分離
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

モバイルアプリをインジェクションから保護する方法

Code Injectionからの保護には、コード、インフラストラクチャ、開発プロセスをカバーする体系的なアプローチが必要です。単一の方法では完全なセキュリティを保証できません。実践の組み合わせが必要です。

第一レベルは予防です。すべての入力データの厳格な検証。アプリケーションがユーザー、別のアプリケーション、またはネットワークから受け取るすべてのフィールドは、タイプ、長さ、形式についてチェックされる必要があります。OWASP ESAPIのようなライブラリは、一般的なシナリオのための既製のバリデータを提供します。

第二レベルはサニタイズとエスケープです。SQLクエリ、HTMLテンプレート、またはシェルコマンドで使用する前にデータを変換します。パラメータ化クエリはSQL Injectionを完全に排除し、HTMLエスケープはXSSを防ぎます。AndroidでSQLiteを扱うには、Room（バインドパラメータを自動的に適用するORM）を使用してください。

第三レベルは権限の最小化です。アプリケーションは最小限の必要な権限で動作する必要があります。データベース、ファイルシステム、プロセス間通信には最小権限の原則を使用します。iOSはアプリケーションサンドボックスを通じてこの原則を実装し、Androidはパーミッションモデルとプロセス分離を通じて実装します。

第四レベルは監視と対応です。不審な操作のログ記録、異常の検出、攻撃の繰り返し時の自動ブロック。Firebase App Checkのようなツールは、侵害されたクライアントからのバックエンドへの偽のリクエストを検出するのに役立ちます。RASP（Runtime Application Self-Protection）の統合により、ランタイムでのインジェクションをブロックできます。

Google Project Zero（2025）の調査によると、これら4つのレベルの組み合わせにより、Code Injection攻撃の成功リスクが94%削減されます。開発者は脆弱性発見後に追加するのではなく、アーキテクチャ設計段階で保護メカニズムを実装することをお勧めします。