top of page
IMG_0546.JPG

診断するとなんだかんだ検出されるシリーズ：エラー型SQLインジェクション：2025/02/18

  • 執筆者の写真: 晋次 宮田
    晋次 宮田
  • 2025年2月18日
  • 読了時間: 4分

1. フレームワークでSQLインジェクションは防げるのか？


近年は、Ruby on Rails、Laravel、DjangoなどのWebアプリケーションフレームワークが普及し、ORM（Object-Relational Mapping）やプリペアドステートメントなどの機能が標準で利用できるようになりました。このおかげで、従来型のSQLインジェクションはある程度防ぎやすくなっています。

しかし、脆弱性診断をしていると「詳細エラーメッセージの管理」が甘いことで、フレームワークの基本対策をすり抜ける攻撃ができてしまうケースがあります。いわゆる、エラー型SQLインジェクションという手法です。



2. エラー型SQLインジェクションとは


エラー型SQLインジェクション（Error-Based SQL Injection）は、データベースが返すエラーメッセージを利用して、DB内部の構造や情報を取得する攻撃手法です。 　アプリケーションがデバッグやテスト目的で詳細エラーを公開していたり、例外処理が不十分でSQLエラーがそのまま返される場合、攻撃者はあえて誤ったクエリを送り込みます。

すると、エラー文にテーブル名、DBバージョン、カラム構造などが記載されてしまい、それらを手がかりに攻撃をさらに深めることができてしまいます。



3. 被害事例


事例1：国内の経済調査会社

本番サイトに詳細エラーメッセージ表示が有効なままになっており、会員テーブル名やカラム名がエラー文経由で流出。攻撃者はその情報をもとにUNIONベースやブラインド型のSQLインジェクションを実行し、最終的に約10万件の会員データ（メールアドレスやハッシュ化パスワード）を盗み出しました。


事例2：大手ECサイトの旧ページ放置

既に運用停止しているはずの旧サイトページにデバッグ用設定が残存。監視対象外だったため、アクセスされても気づけず、数万件規模のユーザ情報が引き出される結果となりました。


事例3：海外就職ポータルでの大規模攻撃

XML関数（UPDATEXML()）を用いたエラー型攻撃により、数十万件の応募者情報が抜かれた事例です。エラー文でDBの構造やバージョンを徐々に特定し、最終的に個人情報が流出しました。



4. 具体的な攻撃手法


4-1. MSSQLの型変換エラー

?id=1' AND 1=CONVERT(INT,@@VERSION)--

文字列をINTに変換できないエラーを引き起こし、そのエラー文に@@VERSIONが表示される仕組みです。バージョン情報はもちろん、db_name()やuser_name()など他のシステム情報にも応用できます。


4-2. MySQLのXMLパスエラー（UPDATEXML / EXTRACTVALUE）

?id=1' AND UPDATEXML(NULL, CONCAT('/', (SELECT version())), NULL)--

存在しないXMLパスを指定することで、エラー文中にversion()の結果がそのまま含まれます。database()やinformation_schemaテーブルを使えば、テーブル名・カラム名も順次推測可能です。


4-3. PostgreSQLの数値キャスト失敗

?id=1' AND CAST((SELECT version()) AS NUMERIC)--

文字列のversion()を強制的にNUMERICへ変換しようとすると、「変換エラー」の詳細にバージョン情報が含まれるパターンです。


4-4. OracleのUTL_INADDRやXMLType

?id=1' AND UTL_INADDR.get_host_name((SELECT banner FROM v$version))--

無効な値によるホスト名取得やXML関連関数でエラーを発生させ、エラー本文中にサブクエリ結果を挿入する手口があります。Oracle環境でも複数のアプローチが存在するので要注意です。



5. 具体的対策


5-1. （これはマスト）本番環境で詳細エラーを表示しない

  • デバッグモードはOFF：RailsやLaravelなど、フレームワークでdebug=falseに設定

  • カスタムエラーページ導入：予期しない例外が発生しても、スタックトレースやクエリ情報は外部に出さない

  • 余裕のないベンチャー企業でもこれはマストにしましょう。


5-2. 通常のSQLインジェクション対策

  • プレースホルダ付きクエリ：SQL文を文字列連結しない

  • 入力バリデーション：想定外の文字や型を排除

  • DBユーザの権限最小化：SELECTだけ許可、不要なCREATE/DROP等は不可に

    • 権限周りの脆弱性があると意味を成さないですが。

  • パッチ適用・脆弱性スキャン：DBMS自体の脆弱性を放置しない


5-3. エラーログは内部で安全に管理

  • 詳細な内容はログにのみ残す：原因調査には必要だが、ユーザーには抽象化したメッセージだけ返す

  • インフラやWAFと連携して異常検出：特定IPから同種のエラーが連続する場合などをアラートで検知


5-4. （できたら）WAF・監視・レガシーページの整理

  • WAF導入：機械学習型エンジンが難読化された攻撃も検出

  • レガシーサイトの定期点検：不要なページやテスト用サブドメインを放置しない

  • ログ監査：連続するSQLエラーや異常なHTTPリクエストを見逃さない



6. 最後に


  • エラー型SQLインジェクションは2025年段階ではもう古典的と言える手法ではあるものの、診断をすると、DBのエラーメッセージを検出できるケースは結構あります。とくに「自社で開発せず、SIerに委託して作ってもらった」というときには、発注元としては注意が必要です。発注元の情報システム部の方で、要求から漏れないように開発を進めるべきでしょう。

 
 
bottom of page