モバイル開発におけるSQL Injection：概要、攻撃手法、防御策

SQL Injectionとは？

SQL Injectionは、アプリケーションがユーザーデータとの文字列連結によってSQLクエリを構築する際に発生する脆弱性です。攻撃者は、特別に細工された文字列をクエリパラメータに渡すことでSQLコマンドの構造を変更します。注入された文字列はデータではなくSQLコードの一部となり、攻撃者はデータベースに対して任意のクエリを実行できるようになります。Verizonデータ漏洩レポート（2025年）によると、SQL Injectionは調査されたすべてのデータ漏洩の8%に存在します。

なぜSQL Injectionは今でも問題なのか？

よく知られた脆弱性であるにもかかわらず（1990年代後半に初めて言及）、SQL Injectionは現代のアプリケーションでも依然として発見されています。その理由は人為的エラーです。開発者は文字列連結を使用したコードを作成し、レガシーコードはリファクタリングされず、ORMフレームワークは不適切に使用されます（例：文字列補間を使用したrawクエリ）。Veracode（2026年）によると、スキャンされた全アプリケーションの約14%に少なくとも1つのSQLi脆弱性が含まれています。

攻撃者は何ができるのか？

SQL Injectionが成功すると、攻撃者は幅広い能力を手に入れます。パスワードハッシュやユーザーの個人データを含むあらゆるデータベーステーブルの読み取り、レコードの変更や削除、管理操作（DROP TABLE、TRUNCATE）の実行、一部の構成ではxp_cmdshell（MSSQL）やINTO OUTFILE（MySQL）を介したリモートコマンド実行が可能になります。結果はユーザーデータの漏洩からシステムの完全な制御喪失まで及びます。

SQLインジェクションの種類

SQLインジェクションは、データベースからデータを抽出する方法によって分類されます。方法の選択は、アプリケーションがクエリ結果とエラーメッセージをどのように処理するかに依存します。OWASP分類では、3つの主要なタイプが特定されています。In-band（同じチャネルを介したデータ抽出）、Inferential/Blind（論理的推論）、Out-of-band（別のチャネルを介したデータ転送）です。

In-band SQL Injection（古典的）

最も一般的なタイプです。攻撃者はクエリパラメータにSQLコードを注入し、その結果がサーバーの応答に直接表示されます。Error-based（DBエラーメッセージ経由）とUNION-based（UNION SELECT演算子経由）の2つのサブタイプがあります。Error-basedは、テーブル名やクエリ構造を明らかにするMySQLの構文エラーなど、エラーメッセージからの情報を利用します。UNION-basedは、正当なクエリの結果をデータベースの他のテーブルのデータと結合することを可能にします。

Blind SQL Injection（ブラインド）

アプリケーションがクエリ結果やエラーメッセージを表示しない場合に使用されます。攻撃者は論理条件を含むクエリを送信し、サーバーの応答の違い（応答時間やページ内容など）を分析することではい/いいえの質問を行います。Time-based Blind SQLiは、条件を確認するために遅延関数（SLEEP、WAITFOR DELAY）を使用します。条件が真の場合、ページの読み込みに時間がかかります。この方法は非常に低速で、1つのレコードを抽出するのに数時間かかることがあります。

# Blind SQL Injectionの例（時間ベース）
# SQLiに脆弱な場合、条件が満たされるとSLEEP(2)が実行される
import requests
import time

payload = "' OR IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(2),0) -- "
url = "http://example.com/user?id=1" + payload

start = time.time()
response = requests.get(url)
elapsed = time.time() - start

# 応答が>2秒後に届いた場合 — パスワードの最初の文字は'a'
print(f"Time: {elapsed:.2f}s - First letter is 'a'" if elapsed > 2 else "First letter is not 'a'")

Out-of-band SQL Injection

データはHTTP応答ではなく、代替チャネル（DNSクエリ、外部サーバーへのHTTPリクエスト、SMTP）を介して送信されます。アプリケーションがクエリ結果を返さず、エラーも表示しない場合に使用されます。MySQLはDNSクエリをトリガーできるLOAD_FILE()関数をサポートしており、MSSQLにはリモートSMBサーバーにデータを送信するxp_dirtreeがあります。Out-of-band SQL Injectionは効果的ですが、攻撃者側の追加サーバー設定と特定のDB関数が必要です。

SQLインジェクションの仕組み

SQL Injectionのメカニズムは、SQLが文字列リテラルに引用符を使用することに基づいています。アプリケーションがユーザー入力をエスケープせずにSQLクエリに直接挿入する場合、攻撃者は文字列を“閉じて”任意のSQLコードを追加できます。例えば、クエリSELECT * FROM users WHERE name = '$input'に' OR '1'='1を挿入すると、SELECT * FROM users WHERE name = '' OR '1'='1'に変換され、すべてのユーザーが返されます。

典型例：認証バイパス

クエリSELECT * FROM users WHERE username = '$user' AND password = '$pass'を使用するログインフォームを考えます。攻撃者がユーザー名フィールドにadmin' -- を入力し、パスワードを空のままにすると、結果のクエリはSELECT * FROM users WHERE username = 'admin' -- ' AND password = ''になります。--文字は残りのクエリをコメントアウトし、パスワードチェックを無効にします。サーバーはadminユーザーのレコードを返し、攻撃者はパスワードを知らなくてもログインできます。

# SQL Injectionの例 — 認証バイパス
# 脆弱なコード：直接の文字列連結
def login_vulnerable(username, password):
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    cursor.execute(query)
    return cursor.fetchone() is not None

# username = "admin' --" がパスワードチェックを無効化
# 安全なバージョン：パラメータ化クエリ
def login_secure(username, password):
    query = "SELECT * FROM users WHERE username = %s AND password = %s"
    cursor.execute(query, (username, password))
    return cursor.fetchone() is not None

UNION-based：他のテーブルの読み取り

UNION SELECT演算子は、2つのSELECTクエリの結果を結合できます。攻撃者が脆弱なパラメータを見つけた場合、別のテーブルからのクエリとともにUNION SELECTを追加します。例：' UNION SELECT username, password FROM admins --。成功の条件は、両方のクエリのカラム数が一致することです。カラム数はORDER BYによって決定されます（' ORDER BY 1--、次に2、3...エラーが発生するまで）。カラム数がわかれば、攻撃者は同じフィールド数のUNION SELECTを挿入します。

モバイルアプリケーションにおけるSQL Injection

モバイルアプリケーションは、サーバーサイド（API）とクライアントサイド（ローカルデータベース：SQLite、Realm）の両方でSQL Injectionに直面します。モバイルAPIでのサーバーサイドSQLiはWebアプリケーションと同様ですが、ローカルデータベースは追加の攻撃ベクトルを生み出します。アプリケーションがSQLiteにデータを保存し、文字列連結でクエリを実行する場合、APIを介してローカルデータベースに入力された悪意のあるデータが後続の処理でSQLiを引き起こす可能性があります。

Android/iOSのSQLiteにおけるSQL Injection

デバイス上のローカルSQLiteデータベースも、アプリケーションが文字列連結でクエリを構築する場合、SQL Injectionに対して脆弱です。AndroidのContent ProvidersとiOSのCore Dataはデフォルトでパラメータ化を使用しますが、rawクエリには開発者の注意が必要です。SQLiteはセミコロンで区切られた複数クエリをサポートしていないため、攻撃者の選択肢は制限されますが、WHERE条件によるデータ読み取りは防げません。AndroidではselectionArgs、iOSではパラメータ付きのNSPredicateを常に使用してください。

モバイルアプリケーションAPIを介したSQL Injection

モバイルアプリケーションが通信するAPIは、他のWebサーバーと同様に脆弱です。モバイル開発者はSQLiをバックエンドだけの問題と考えることがよくありますが、脆弱性はクライアントからパラメータを受け入れるAPIエンドポイントで発生します。責任の分離は保護にはなりません。バックエンド開発者がクエリのパラメータ化を忘れた場合、ユーザーのモバイルアプリが攻撃ベクトルになります。バックエンドにORMまたはプリペアドステートメントの使用を要求してください。

// AndroidのローカルSQLiteにおけるSQL Injectionの例
// 脆弱なコード：直接連結
fun getUserVulnerable(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = $userId", null
    )
}

// 安全なバージョン：selectionArgsによるパラメータ化
fun getUserSecure(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = ?",
        arrayOf(userId)
    )
}

SQL Injectionの防止方法

SQL Injectionからの保護は単純な原則に基づいています。SQLクエリでユーザー入力を決して信頼しないことです。唯一信頼できる方法は、SQLコードとデータを別々に渡すクエリパラメータ化（プリペアドステートメント）です。エスケープ、検証、WAFなどの他のすべての方法は追加のセキュリティレイヤーですが、パラメータ化の代わりにはなりません。OWASP（2025年）によると、パラメータ化はSQL Injection攻撃の100%を防ぎます。

プリペアドステートメント（パラメータ化クエリ）

プリペアドステートメントを使用する場合、SQLクエリは最初にDBサーバーによってデータなしでコンパイルされ、その後パラメータ値が別々に渡されます。データベースはパラメータを実行可能コードではなくデータとして扱います。攻撃者が' OR '1'='1を渡しても、データベースはそれをSQLコードではなく文字列値として解釈します。プリペアドステートメントは、PHPのPDO、JavaのPreparedStatement、Pythonのcursor.executeなど、すべての最新言語とフレームワークでサポートされています。

ORMフレームワークとクエリビルダー

最新のORM（Hibernate、Entity Framework、SQLAlchemy、Room）は、開発者がrawクエリに切り替えない限り、クエリ実行時に自動的にパラメータ化を使用します。ただし、ORMは完全には保護しません。JPAの@Query(value = "SELECT * FROM users WHERE name = :name", nativeQuery = true)のような構造では、連結ではなく名前付きパラメータを介してパラメータを渡す必要があります。クエリビルダー（Knex、jOOQ）も、rawメソッドを使用しない場合はデフォルトでクエリをパラメータ化します。

文字列エスケープ（主要な方法としては非推奨）

特殊文字のエスケープ（mysql_real_escape_string）は、すべてのタイプのSQL Injectionから保護しない時代遅れの方法です。問題は、エスケープがエンコーディングに依存し、マルチバイトエンコーディング（アジアのシステムでのGBKなど）を使用するとバイパスされる可能性があることです。エスケープは、パラメータ化が不可能なレガシーコードでのみ、かつ常に厳格な入力タイプ検証と組み合わせて使用してください。

データベースの最小権限の原則

アプリケーションアカウントには必要最小限の権限（SELECT、INSERT、UPDATE、DELETE — アプリケーションが実際に必要とするテーブルのみ）を付与する必要があります。アプリケーションアカウントでのDROP、TRUNCATE、CREATEの使用を禁止します。これにより、SQL Injectionが成功した場合でも被害を限定できます。攻撃者はテーブルを削除したり管理操作を実行したりできなくなります。

SQLインジェクションを検出するツール

定期的なSQL Injectionテストはセキュア開発パイプラインの一部であるべきです。静的解析、動的スキャン、手動ペネトレーションテストの組み合わせが最良の結果をもたらします。Synopsysサイバーセキュリティレポート（2025年）によると、自動スキャナーはSQLi脆弱性の最大70%を発見しますが、複雑なBlind攻撃には手動テストが必要です。

• sqlmap — SQL Injectionの自動検出と悪用のための最も人気のあるツール
• OWASP ZAP — アクティブSQLiスキャンモジュールを備えた無料のDASTスキャナー
• Burp Suite Scanner — 自動SQL Injection検出機能を備えたプロフェッショナルツール
• SonarQube — SQLiパターンを含む脆弱性の静的コード解析
• CodeQL — ソースコード内のSQLインジェクションを発見するためのセマンティックコード解析

モバイルアプリケーションの場合、ローカルSQLiteの解析も重要です。すべてのrawQuery呼び出し、ContentProviderクエリ、rawQueryを使用したRoomクエリを確認してください。ツール：Android Studio Lint（SQLiteのSQLiを検出）、MobSF（Mobile Security Framework）によるAPK/IPAの自動静的・動的解析。また、モバイルアプリケーションのトラフィックをプロキシインターセプトしながらsqlmapを使用してAPIエンドポイントをテストすることをお勧めします。